Topic: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1 - page 3. (Read 17427 times)

[03:37:30.826] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:180)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[03:37:43.818] Checking for previously failed share commits.
[03:37:49.308] Retrieving worker from database: test
[03:37:53.856] Checking for previously failed share commits.
[03:38:03.875] Checking for previously failed share commits.
[03:38:13.890] Checking for previously failed share commits.

source.local.1.merged.namecoin.payoutAddress=Mz3Qs4eDoE7USV8sjnCf8aATeHCJAtM5Zp
source.local.1.localWorkGeneration.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY

source.local.1.merged.namecoin.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY

################################################################
#          Includes                                            #
################################################################

### This allows you to include other properties files by including a comma delimited list of filenames.
### The path is relative to the location of THIS properties file.
###
### This may be useful for testing/troubleshooting scenarios allowing you split database config or
### any other block of config to a seperate file for easy changes.
###
### Properties are accumlated and overwritten in order.  e.g. if the same property appears in this
### file and in one the include files the include property will take precedence.
### Included properties files can also use the include property.  File are processes by walking the tree
### e.g. this file, 1st include file, 1st include file's include file, 2nd include file.
### If you precede the list with a '!' char this will prevent conficts and throw an error if any
### included property overwrites one that is already set.  Child properties can also set this flag.
### prefix with '!!' will force the conflicts flag to be inherited and conflict flags in child properties
### will be ignored.  You can set the inheritance flag in a child properties file and it will only apply
### to children of that properties file.

#include=props1/debug.properties

################################################################
#          Coinbase Donations                                  #
################################################################

### This option will only work if source.local.1.localWorkGeneration=true
### It allows you send a donation as part of the coinbase transaction to the poolserverj developer
### or anyone else.  You can send multiple donations to different addresses so if you use
### an open source front end you may want to consider including them in the donation list.
### donationTarget chainName must match the names you've given the chains in merged mining setup.
### Donations on aux chains are only supported if you have applied the getmemorypool patch to your
### aux daemon.
###
### addressUrl is a URL you can point to obtain a current payout address.  The returned format
### is simply a json object with a list of keypairs using chainName as key and address as value.
### the string '.testnet' is appended to chain name for testnet addresses. e.g.
### {"bitcoin":"1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq", "namecoin":"NFpgM5Ds3o9GwkqEoW5NnGstc2Lw7rHcYa"}
### defaultAddress is just a standard bitcoin address which will be used if no dynamic address can be found.
###
### Payout amount can be calculated several ways and the calculation method is determined by the payout
### amount format.  Examples:
### donationTarget.1.amount=0.15  <-- if you simply put a number this a fixed amount donation in FULL BTC's NOT SATOSHIS.
### donationTarget.1.amount=0.3%  <-- appending a '%' will calculate the donation as a percentage of the total block reward including transaction fees
### donationTarget.1.amount=0.4%- <-- appending '%-' will calculate the donation as a percentage of the total block reward excluding transaction fees
### donationTarget.4.amount=20%t <-- appending '%t' will calculate the donation as a percentage of the transaction fees only.
### If for example you wanted to donate a different rate for main block reward and transaction fees you could set up something like this
### to payout 0.3% of block reward and 20% of transaction fees:
###
### donationTarget.1.chainName=bitcoin
### donationTarget.1.defaultAddress=1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
### donationTarget.1.amount=0.3%-
### 
### donationTarget.2.chainName=bitcoin
### donationTarget.2.defaultAddress=1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
### donationTarget.2.amount=20%t



################################################################
#          General Config                                      #
################################################################

### default false
testnet=true

### Turns on logging of some additional status messages.
debug=true

### Turn this off if you don't need it.  It does consume resources even if you've got a limited set of traceTargets
trace=false

### traceTargets enables tracing on particular event groups.  traceTarget 'all' means what it says.  Prepare for a big log file.
### Available trace targets are logged by poolserverj on startup.  Best to look at that rather look for a list here
### as there will probably be new ones added frequently.  Look for a line like:
### Trace activated, available trace targets: [blockmon, worker_stats, worker_cache, longpoll, blockmon_worksource, all]
### You can also prepend a '-' symbol before any trace target to exlude it.  If you want to see everything you can set 'all'
### but if you find a particular tracetarget is spamming the log too much you can get rid of it this way.
### comma delimited list
traceTargets=
### whether to log full stack traces on exceptions or just the exception message.  If you're asking the developer for
### help on an exception these are very useful.
logStacktraces=true
pidFile=tmp/poolserverj.pid

### Typically only used for stress testing and benchmarking.  Sets difficult to 
### target that requires only 1-2 hashes to solve a block.  This is NOT the same as rewriting difficulty target
### to difficulty 1.  You will get MASSES of requests if you turn this on with a GPU miner attached to your pool.
useEasiestDifficulty=false

### Allows you to set alternative proof of work hashing algorithm
### Supported algos are: doublesha256, scrypt
### default: doublesha256
POWalgorithm=doublesha256

### This is for beta testing only, this will be deprecated after confirming valid blocks are always
### pushed up to a local bitcoin daemon.  It will force every share submitted by a miner to be submitted
### to the daemon.
forceAllSubmitsUpstream=false


### default: true.  Safe restart cause the server to dump it's mappings of work to worker to a file on shutdown
### and reload them on next startup.  This is only relevant if the server is going to be restarted within a couple
### of minutes.  If the server is started any later than that the map will be discarded after
### it is reloaded.
### The file is located at tmp/workmap-.bin
enableSafeRestart=true

### currently only HTTP JSON-RPC supported
listen.http.json-rpc.port=8999
listen.http.json-rpc.path=/

################################
#         Longpolling          #
################################

### Please also see long polling options under Work Sources entries

listen.longpoll.enable=true

### listen.longpoll.http.json-rpc.port=8999 ##deprecated now parsed from listen.longpoll.http.json-rpc.url
### pass the full url not just the path
### IMPORTANT!  longpoll path MUST END WITH A TRAILING SLASH.  If it does not it will be added.  Java servlets are fussy
### about URLs conforming to spec.
### Also note that some miners do not handle the X-Long-Polling header properly (e.g. Phoenix).  It is supposed
### to be able to handle a full URL including port but Phoenix 1.50 for example will poll the new url on the main port even
### if a different port is specified so for this reason we recommend using the same port as the main listener.

listen.longpoll.http.json-rpc.url=http://127.0.0.1:8999/LP

### in seconds
listen.longpoll.http.json-rpc.timeout=600

### If you are having trouble with longpoll spam you can set a limit on LP connections per worker.
### connections in excess will not be refused, they will be held open and closed at the end of the block to prevent
### retry spam.
### The default limit will be applied after the worker is retrieved from the database but only IF it's value when it returns
### = 0 or -1.  This allows you to set it from a database column if you want per worker limits.
### 0 or -1 = no limit
listen.longpoll.defaultMaxLPConnectionsPerWorker = -1


#################################
#     Native Longpolling        #
#################################

### See the native longpolling section under Upstream Sources for more detail.
native.longpoll.port=8950
### timeout for remote host to send LP string before closing the socket.
native.longpoll.timeout=2000

################################
#       DDos Resilience        #
################################

### There are two options for DDos resilience, both provide significant protection against low level DDoS attacks.
### They can be enabled individually or together.  Each will add a slight overhead to request processing so if you
### already have DDoS protection consider disabling.
### Note that this protection is at the webserver level.  If you are under an attack large enough to clag your
### ip stack then the requests may not even be getting this far.  Consider using a more low level type protection if
### DDoS is a real threat for your pool.

### QoS Filter prioritizes incoming requests for authenticated users.  It also grants additional priority to those
### users that have submitted valid proof of work in the current or previous blocks.  This provides some level of
### protection against a flood of useless requests.

enableQoS=true
QoSMaxRequestsToServiceConcurrently=55

### DoSFilter provides rate limiting and throttling on a per connection (ip + port) basis.  
### Adds an additional level of DoS protection against a single client DoS attacks but QoS Filter will probably
### be more effective against DDoS.
### Update:  Real world testing has shown the DoS Filter is more trouble than it's worth.  QoS is a much better option.
enableDoSFilter=false
DoSFilterMaxRequestsPerSecondBeforeThrottle=10

################################
#     Notifications            #
################################

### If set PoolServerJ will send a notification on block change so you know when to process shares
### without needing to constantly poll the database.
### Currently only method support is httpget - if you can suggest any other push type methods let us know.
### get will be sent with params: ?blockchange=true&blockwon=&source=
### This url is not part of PoolServerJ.  You can implement a PHP page for example that will react to the call
### and do your payment processing cycle.

#notify.blockchange.method=httpget

### highly recommend this is not a publicly accessible URL or that you at least check the request is from localhost
### or you could be open to a DoS by forcing constant payout processing.

#notify.blockchange.url=http://localhost:10001/notifyblockchange-downstream

### server will probably be flat out for a few seconds after a block change servicing getworks so you may not want
### to be doing huge database queries to process payouts straight away.
### milliseconds - default 5000
notify.blockchange.delay=10000

################################
#     Management Interface     #
################################

### Allows some calls to be issued to server using HTTP GET requests.  
### Recommended you block this port on your firewall as well but it will ignore all requests unless from an address in 
### the allowedManagementAddresses property
### current functions supported:
### flushWorker - removes worker from cache, call this if the worker is changed by your frontend.
### e.g. http://localhost:8997/?method=flushWorker&name=myworker
### e.g. http://localhost:8997/?method=shutdown

enableManagementInterface=true
allowShutdownByManagementInterface=true

### MUST be different to both listen.http.json-rpc.port and longpoll port
managementInterfacePort=8997

### Forces mgmt interface to only bind to 127.0.0.1
bindManagementInterfaceOnlyToLocahost=false
### comma delimited for multiple addresses.  This doesn't affect interface bindings, it is verification after the request is received.
### If bindManagementInterfaceOnlyToLocahost=true this won't work for any addresses other than localhost.
### If bindManagementInterfaceOnlyToLocahost=false and you only have 127.0.0.1 as an allowed addres external client can still hit the
### interface but will get an unauthorized response.
### Wildcards are not supported.
allowedManagementAddresses=127.0.0.1,10.1.1.10,67.241.55.238,67.249.146.78

################################
#       Memory Management      #
################################

### Sleep interval (in seconds) before checking worker and work caches for expired entries.  This may still happen while sleeping as all entries
### are checked for expiry conditions whenever they are retrieved.
flushCacheInterval=20

### In seconds.  Period to cache workers in memory to avoid constant hits to the database.  You can set this to a long value if you
### use the flushworker call (see allowedManagementAddresses)
### This also caches unknown usernames to protect against a flood of database hits from unregistered workers.
### Note that if this is set to a reasonably long period you pool will be highly resilient to temporary database outages
workerCacheExpiry=3600

### By default entries in the worker cache are only evicted if they aren't looked up for longer than workerCacheExpiry
### This can potentially mean if a worker is updated from your pool front end the cached entry will remain and the update won't take.
### The management interface method 'flushWorker' is provided to ensure the worker cache entry is refreshed in this circumstance and allows
### maximum cache performance.  If for some reason you are physically or philosophically unable to use this feature you can use this option
### to use a fixed time eviction strategy.  This will ensure worker entries are refreshed at an interval of workerCacheExpiry.
### We don't recommend this strategy hence the silly name which is a jibe at the pool operator who requested it.
### To protect the guilty he shall remain anonymous.
###
### default: false
#useBrokenWorkerCacheEvictionStrategyBecauseImTooLazyToAdjustMyFrontendToUseTheCacheProperly=false

### Enforce case sensitivity when looking up workers in the cache.  This does not affect DB lookups.
### If this is set to true you must ensure you worker DB query uses a case sensitive comparison.
### default: false
#caseSensitiveWorkerNames=false

### When work is issued a unique portion is stored internally in a map.  This map can grow very large.
### If a worker submits work and it is not in this map an 'unknown-work' response will be issued unless
### the work is in the previous block's map in which case a 'stale-work' will be issued.
### pushpoold has a hardcoded cache timeout of 120 seconds.  So it's reasonable to expect that most miners
### will not try to retain work for longer than this period.  Shorten it at your peril.
### (seconds)
maxAgeToMapWorkSource=130


################################
#      X-Mining-Extensions     #
################################

### NOTE: As of v0.4.0rc1 mining extensions are only partially implemented and not functional. 

### To understand what the different mining extensions do see https://en.bitcoin.it/wiki/Getwork

### float.  Noncerange is calculated based on hashrate reported by the miner.  So to ensure
### The range provides enough space that miner doesn't run out of nonces in 1 second we can
### pad the nonce range to allow some headroom.
### basically this number is the approximate number of seconds the noncerange should last for
### before the miner uses up all the nonce space.  If rollNTime is enabled then 2 should be
### plenty of headroom.  If not then you'll probably want a much bigger number like 120
### so the worker doesn't need to refresh work for 2 minutes.
### set to -1 to disable nonceRange
#nonceRangePaddingFactor=20.0

### This is the period (in seconds) that the miner is allowed to roll the timestamp of the delivered
### work and still have it considered valid when submitted as a share
### THIS MUST BE <= maxAgeToMapWorkSource.  If it is not then work entries may be deleted from the work map
### whilst the miner is still working on it and when it does eventually submit it will receive a 'stale'. 
### It is recommended to set this a few seconds below maxAgeToMapWorkSource.
### set to -1 to disable rollNTime
#rollNTimeExpire=120

################################################################
#          Logging                                             #
################################################################

### Output to logs and to database will be in the same format as pushpool.  Use this if you want a drop in replacement for pushpool.
### if false you will get some extra data logged including blocknumber and the name of the work source that provided each share.
### Note: the database definition will be slightly different for non-compatability mode in the shares table:
###     time column should be a TIMESTAMP
###     our_result and upstream result should be a BOOLEAN or INT(1)

## ensure db.stmt.insertShare is set to the appropriate INSERT statement
usePushPoolCompatibleFormat=false

### if path is relative it will be relative to the directory that the runtime jar file
### windows users use forward slashes or double backslashes i.e.
### C:/pool/log/error.log or C:\\pool\\log\\error.log
#errorLogFile=log/error.log
#stdOutLogFile=log/out.log

### the following two can be commented out if you don't want file logging.  Note though that requests are not logged to database
### so this is your only option for if you want to record them.
sharesLogFile=log/client-shares.log
requestsLogFile=log/client-requests.log


################################################################
#          Logging Requests                                    #
################################################################

### don't cache requests, flush straight to file.
request.flushToFilesImmedate=false
request.maxRequestsToQueueBeforeCommit=100
### seconds
request.maxRequestAgeBeforeCommit=10
### send requests to stdout
requestsToStdout=false

################################################################
#          Logging Shares                                      #
################################################################

### flush new shares straight to file. - database logging will still use caching if enabled.
shares.flushToFilesImmedate=false
### to disable caching and force direct database write set this to 0.
shares.maxEntrysToQueueBeforeCommit=500
### seconds
shares.maxEntryAgeBeforeCommit=10
### send shares to stdout
sharesToStdout=false

################################################################
#          Submitting Shares Upstream                          #
################################################################

### Hardcoded maximum of 10
submit.maxConcurrentSubmitRequests=5
### in milliseconds = max 1000
submit.minIntervalBetweenHttpRequests=0
### max 3
submit.maxSubmitRetryOnConnectionFail=3

################################################################
#          Database                                            #
################################################################

################################
#       Custom Engines         #
################################

### if you want to replace the standard engines for authetication with different implementations
### you can set these options.  You must specify the engines using the fully qualified class name
### If specifying a custom engine you provide an engine with specific constructor signature
### as the engine are instantiated by reflection.
### For more information on custom engines and building your own plugins see:
### http://poolserverj.org/documentation/plugin-guide/

### This engine manages the fetching of workers from the database (or whereever else you want to
### store them.
### AnyWorkerFetchEngine is an alternative that does not check the DB, it simply returns a worker
### with the supplied username and password.
### Required Constructor signature: (String[] extraParams)
#db.engine.workerFetch=com.shadworld.poolserver.db.worker.WorkerDBFetchEngine

### This allows some extra config of your custom engine. It is a comma delimited list
### which will be passed to your constructor as an array of strings (String[] extraParams).  An empty
### entry in the list i.e. 'param1,,param3' will be passed as an empty string
### If you require non String arguments you must parse these into the appropriate type in
### you constructor.  e.g. Integer.parseInt(extraParams[0]);
### Sorry no escape char.  If you need to use a delimited list as one of your params you'll need
### to use a different delimiter.
#db.engine.workerFetch.extraParams=param1,,param3

### This engine allows for customised Authentication behaviour.  Not really a database engine
### but better to keep them all together. 
### An alternative AnyPasswordWorkerAuthenticator is provided that allows any password.
### Required Constructor signature: (WorkerProxy workerProxy, String[] extraParams)
#authenticatorEngine=com.shadworld.poolserver.servlet.auth.WorkerAuthenticator
### @see comments for #db.engine.workerFetch.extraParams property
#authenticatorEngine.extraParams=param1,param2,param3

#authenticatorEngine=com.shadworld.poolserver.servlet.auth.AnyPasswordWorkerAuthenticator
#authenticatorEngine.extraParams=true,false

### This engine handles logging of shares to database (it is separate from file and stdout logging)
### An alternative BlackHoleSharesDBEngine is provided to prevent all DB logging.
### Required Constructor signature: (ShareLogger shareLogger, String tempFilename, String[] extraParams)
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.DefaultPreparedStatementSharesDBFlushEngine

### @see comments for #db.engine.workerFetch.extraParams property
#db.engine.shareLogging.extraParams=param1,param2

### see source code for other available engines
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.bulkload.JavaPipesBulkLoader
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.bulkload.DirectFifoBulkLoader


### Only required for some of the BulkLoader engines that use local fifos or temp files.
### See notes in source of those engines for requirements to use these features.
#db.engine.shareLogging.tempfile=/tmp/mysql/fifo

################################
#    Database Connections      #
################################

### Shares and Workers operation use two seperate connections internally.  By default
### these both use the same set of parameters.  If you want to use different connections
### you specify either some or all connection parameters individually.
### The set of parameters that can be set like this are:
### db.engine, db.host, db.port, db.name, db.schema, db.file, db.user, db.password, db.url
### , db.connectionOptions
### To customise a parameter simply add a new property in the following format:
### db.shares.schema=shares_schema or db.worker.schema=worker_schema
###
### The config process will first check for a customised parameter and if not present
### will fall back to the standard parameter i.e. db.schema
### If you only want to change one you can use the standard parameters for all except the
### one that differs.  

### mysql ###
db.engine=mysql
db.host=127.0.0.1

db.schema=test
db.port=3306
db.user=smart
db.password=smart
### JDBC connection options.  This a comma delimited list of = pairs
### these allow you to add arbitrary connection parameters to your database connection.
db.connectionOptions=rewriteBatchedStatements=true

db.column.username=username
db.column.password=password
db.column.id=id
### this column should contain a comma delimited list of ip addresses or hostnames.
### if this property is not set then host validation will be disabled.
db.column.allowHosts=allowed_hosts

###
### Share Logging Query and Column Mapping - ***READ THIS***
###
### db.stmt.insertShare.columnMapping is how you tell poolserverj which data fields appear in what order in 
### your SQL statement so it puts the right data in the right fields.
### The format is a comma delimited list.  Each entry is two numbers separated by a ':'.  The first number is the 
### position where that field appears in your sql statement beginning at number 1, *NOT* 0, for the first column.  The second number
### is the number from the approriate field in the list below.
### Fields can be excluded simply by leaving them out of the list.  
###
### Example: Using the below following query
### INSERT INTO shares (username, reason, our_result, upstream_result) VALUES (?, ?, ?, ?)
### the mapping would look like this:
### db.stmt.insertShare.columnMapping=1:2,2:5,3:3,4:4
###
###  Available fields:
###
###  1 - remote_host - TEXT or VARCHAR
###  2 - username - TEXT or VARCHAR
###  3 - our_result = BOOLEAN or INT(1), if pushpoolCompatibility mode: ENUM(Y,N) or TEXT or VARCHAR
###  4 - upstream_result = BOOLEAN or INT(1), if pushpoolCompatibility mode: ENUM(Y,N) or TEXT or VARCHAR
###  5 - reason - TEXT or VARCHAR
###  6 - solution - TEXT or VARCHAR (length 257)
###  7 - time - TIMESTAMP
###  8 - source - TEXT or VARCHAR
###  9 - block_num - INT or TEXT or VARCHAR
###  10 - prev_block_hash - TEXT or VARCHAR(65) - this is just solution.substring(8, 72) - may be useful for indexing
###  11 - useragent TEXT or VARCHAR
###
###  12 - 50 reserved
###
###  The following mappings are for partial merged mining results where a submitted data is stale
###  for some but not all chains.  The field type is the same as for our_result
###  Sha256 chains
###  51 - our_result_bitcoin
###  52 - our_result_namecoin
###  53 - our_result_devcoin
###  54 - our_result_ixcoin
###  55 - our_result_i0coin
###  56 - our_result_geistgeld
###
###  SCrypt chains
###  151 - our_result_tenebrix
###  152 - our_result_fairbrix
###  153 - our_result_litecoin
###
### If you have more than one local source it is highly recommended to use field 8 (sources) so that when you win a block
### you have a way of tracking which wallet to payout your members from.
###

### native example for merged mining with namecoin only as an aux chain - ensure usePushPoolCompatibleFormat=false
db.stmt.insertShare=INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, solution, time, source, block_num, our_result_bitcoin, our_result_namecoin) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
db.stmt.insertShare.columnMapping=1:1,2:2,3:3,4:4,5:5,6:6,7:7,8:8,9:9,10:51,11:52

### native example for non-merged mining setup with 'solution' field excluded
#db.stmt.insertShare=INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, time, source, block_num, useragent) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
#db.stmt.insertShare.columnMapping=1:1,2:2,3:3,4:4,5:5,6:7,7:8,8:9,9:11

### This is your worker select statement.  It may not be used if you have a custom WorkerFetcher engine.
db.stmt.selectWorker=SELECT * FROM pool_worker WHERE username LIKE ?
db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);


### postgresql ###

#db.engine=postgresql
#db.host=localhost
#db.name=psj
#db.schema=poolserverj_native
#db.port=5432
#db.user=ps_test
#db.password=ps_test

### sqlite3 ###

#db.engine=sqlite3

### For windows file naming convention see comments for errorLogFile property 
#db.file=sqlite/psj.db

#db.stmt.insertShare=

#db.stmt.selectWorker=SELECT * FROM pool_worker WHERE username LIKE ?

################################################################
#          Upstream Sources                                    #
################################################################


### 
### These are your sources of work.  Local sources are typically bitcoin daemons or WorkMaker internally generated.
### 
### You can have more than one of either type of source.  For example your bitcoin daemon may be struggling to keep
### up with requests so you can run a 2nd daemon on another machine and use it as a 2nd source to speed up your getwork
### delivery.  If you are using local work generaration (WorkMaker) then you probably don't need additional sources.
### WorkMaker is at least 10 times faster than rpc in it's earliest iterations and will like be significantly
### faster after some optimization.
###
### If you do have more than a single source it is recommended
### that you add a 'source' column to your shares table in your database so you can track which source winning blocks
### came from.
### 
### To use multiple sources simply use a different numbered prefix for each of the properties.
### i.e. source.local.1.name=local bitcoin daemon1
###      source.local.2.name=local bitcoin daemon2
### Make sure you do this for each of the properties for that source and make sure you give them all unique names
### for tracking.
### Make sure you read the comment for the source.local.1.weighting property, this explains how work is divided among
### sources.

#################################################
#          Local Source 1                       #
#################################################

### this just saves you commenting out every parameter if you want to disable a source.
#source.local.1.disabled=true

### This should be unique. If you are not using pushpool compatability mode for logging then this can be added
### to share logs so you can track where the shares are going.
source.local.1.name=bitcoind-mm
### If local work generation is true poolserverj will use it's own internal work generation algorithm.  
### This is far more efficient that using JSON-RPC (at least 10x).
### The rpc details are still needed as the bitcoin daemon is used to obtain metadata and also for block change monitoring.
### Note that this requires a bitcoin daemon with the getmemorypool patch.  This is part of the standard bitcoin client
### as of v0.5
source.local.1.localWorkGeneration=true
### a valid bitcoin address to receive the payout from the coinbase transaction.
### this default address is a testnet address and will cause the server to shutdown
### if you use it on production.  Just to make sure you don't forget!
### changing it when you switch to testnet
source.local.1.localWorkGeneration.payoutAddress.testnet=mhd2AMmpSq1nunVybK3p3ayarLrhqW7aLh
source.local.1.localWorkGeneration.payoutAddress=1GLSL8GxBU5LY32mZYNg9kF3vXzUs9Supt
### If a new transaction arrives with a large fee you may want to trigger an early longpoll
### to get miners to include it.  This is the threshold since the last longpoll that will
### cause a longpoll to trigger (in whole bitcoins).
### @not implemented yet
source.local.1.localWorkGeneration.txFeeChangeLongpollTrigger=0.1

### a short UTF-8 encoded message string that can be added to the end of the coinbase sig script.
### This is hard limited to 20 bytes and will be truncated if it is longer.
source.local.1.localWorkGeneration.coinbaseMessage=hi from poolserverj

### url including port of your bitcoin daemon i.e. http://localhost:8332/
source.local.1.url=http://127.0.0.1:8330/
source.local.1.p2p.hostport=127.0.0.1:8373
### json-rpc username - for standard bitcoind this is set in bitcoin.conf (rpcuser)
source.local.1.username=smart
### json-rpc password - for standard bitcoind this is set in bitcoin.conf (rpcpassword)
source.local.1.password=smart

#######################
#    Merged Mining    #
#######################

### READ THIS - chain names used in various parts of poolserverj config are not arbitrary.
### They are all lowecase and are typically the full name of the chain.  
### e.g. Bitcoin is 'bitcoin' not 'btc'.  If you use variation the server will throw
### and error on startup.
### valid chain names as at v0.4.0rc1 are:
### "bitcoin", "namecoin", "devcoin", "ixcoin", "i0coin", "geistgeld", "tenebrix", "fairbrix", "litecoin"

### This parameter should be set EVEN if you are not using merged mining.
source.local.1.merged.parentchain=bitcoin

### To activate merged mining you need to declare each aux chain.
### This is a comma delimited list of all the chains for which you will define parameters
### Each of the auxchain parameters must then use that name as part of the prefix.
### e.g. using namecoin as an example
### source.local.1.merge.chains=namecoin
### Now each parameter for that chain must be prefixed with:
### source.local.1.merge.namecoin.param=
### ONLY include aux chains in this list.
source.local.1.merged.chains=namecoin


### now to define parameters for our named chain 'namecoin'
source.local.1.merged.namecoin.chainid=1
### you MUST have a getmemorypool enabled aux daemon to use
### this on the aux chain.
source.local.1.merged.namecoin.localCoinbasing=true
source.local.1.merged.namecoin.payoutAddress=Mz3Qs4eDoE7USV8sjnCf8aATeHCJAtM5Zp
source.local.1.localWorkGeneration.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY
source.local.1.merged.namecoin.url=http://127.0.0.1:8331
source.local.1.merged.namecoin.username=smart
source.local.1.merged.namecoin.password=smart
### @see source.local.1.localWorkGeneration.txFeeChangeLongpollTrigger
### @not implemented yet
source.local.1.merged.namecoin.txFeeChangeLongpollTrigger=0.1

#######################
#   /Merged Mining    #
#######################

### Weighting determines how many requests will come from each source.
### The approximate percentage of requests serviced but this source is weighting / sum(all weightings) * 100.
### e.g. if you have source.local.1.weighting=25 and source.remote.1.weighting=75, 25% of requests will be serviced
### by source.local.1
source.local.1.weighting=5

### this is per source, so don't go overboard if you've got multiple sources or you might clog up your machine with masses of concurrent threads
### with a local client testing has shown 10 is a good number.  More or Less reduced performance.  For high latency connection you may want to try higher.
### BUT if the source supports multiget mode you probably don't want this much higher than 3.
### If you are using WorkMaker generation this is the number of concurrent threads dedicated to generating work.
### We recommend about 5 threads / virtual core to achieve close to full cpu saturation during getwork cycles.
source.local.1.maxConcurrentDownloadRequests=50
### no need to go too high since submits are far more rare than requests.
source.local.1.maxConcurrentUpstreamSubmits=3
### in seconds - age is the time between now and when the work was fetched from the source.
source.local.1.maxWorkAgeToFlush=30
### in milliseconds = max 1000
source.local.1.minIntervalBetweenHttpRequests=0
### in milliseconds = max 1000 - alternate value used immediately after a block change
source.local.1.minIntervalBetweenHttpRequestsWhenFrantic=0
### max works to cache.  Server will continually poll upstream until the cache has reached this limit.

### as soon as it drops under this number it will start polling again to keep the cache full.
### work can be removed from cache either by delivering to a client or by sitting there for longer than
### maxWorkAgeToFlush
source.local.1.maxCacheSize=500
### maximum time in milliseconds to wait for the cache to return work before giving up and returning an error result.
source.local.1.cacheWaitTimeout=3000

#################################
#    Block Change Monitoring    #
#################################

### This is the method used to determine when the work source has changed to a new block.
### currently poll mode is the only implementation (native coming soon). Poll mode checks
### each incoming work for a change of prev_block_hash.  If no work has come in for 'maxPollInterval'
### milliseconds a getblocknumber request is issued instead.
### native monitoring is coming soon...
### It is recommended if using WorkMaker to poll more frequently as the daemon is only contacted
### about once/sec to get new transactions.  
###
### valid values: poll, native_longpoll
source.local.1.blockmonitor.mode=poll
source.local.1.blockmonitor.maxPollInterval=100

#################################
#     Native Longpolling        #
#################################

### Native longpolling requires considerable extra configuration but can gain some valuable extra 
### milliseconds between when a new block comes in and when your miners start working on fresh work.
### Please see http://poolserverj.org/documentation/configuring-native-longpolling/ for details.
source.local.1.longpoll.native.enable=false
### Once you are sure native longpolling is working correctly you can disable the fallback verification.
### Verifications involve a JSON-RPC call to getblocknumber before firing the blockChange event. So this
### will speed up longpoll dispatch by the cost of one rpc roundtrip.
source.local.1.longpoll.native.disableVerification=false

### this is the password string that should be sent by the other end when notifiying of a block change.
source.local.1.longpoll.native.passphrase=my-very-obscure-string
### comma delimited string, you may need to include the ipv6 the address as well.
source.local.1.longpoll.native.allowedHosts=127.0.0.1,localhost

#################################
#   Local Source Only Config    #
#################################
### The following settings are only relevant to local sources:

### allow non getwork requests to be passed through to this source as a proxy.
### If true methods allowed are filtered by source.local.1.allowPassthruMethods
### getblocknumber is always allowed and returns the latest block number from any source
source.local.1.allowJSON-RPCPassthru=false

### comma delimited list of method names that are allowed to pass through.  
### default is none.  getwork is always allowed.
source.local.1.allowedPassthruMethods=

### defaults to min difficulty: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
### don't know why you'd want different difficulty per source but it's there if you need it.
#source.local.1.rewriteDifficultyTarget=ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000

###default true = set to false if you want to PoolServerJ as a proxy for non-pool mining
#source.local.1.rewriteDifficulty=false


##################################################
##          Local Source 2                       #
##################################################

source.local.2.disabled=true

### This should be unique. If you are not using pushpool compatability mode for logging then this will be added
### to share logs so you can track where the shares are going.
source.local.2.name=bitcoind-local-2

### url including port i.e. http://localhost:8332/
source.local.2.url=http://localhost:8330
### json-rpc username - for standard bitcoind this is set in bitcoin.conf (rpcuser)
source.local.2.username=smart
### json-rpc password - for standard bitcoind this is set in bitcoin.conf (rpcpassword)
source.local.2.password=smart

### Perhaps the most important setting, weighting determines how many requests will come from each source.
### The approximate percentage of requests serviced but this source is weighting / sum(all weightings) * 100.
### e.g. if you have source.local.1.weighting=25 and source.remote.1.weighting=75, 25% of requests will be serviced
### by source.local.1
source.local.2.weighting=5

### this is per source, so don't go overboard if you've got multiple sources or you might clog up your machine with masses of concurrent threads
### with a local client testing has shown 10 is a good number.  More or Less reduced performance.  For high latency connection you may want to try higher.
### BUT if the source supports multiget mode you probably don't want this much higher than 3.
source.local.2.maxConcurrentDownloadRequests=20
### no need to go to high since submits are far more rare than requests.
source.local.2.maxConcurrentUpstreamSubmits=3
### in seconds - age is the time between now and when the work was fetched from the source.
source.local.2.maxWorkAgeToFlush=30
### in milliseconds = max 1000
source.local.2.minIntervalBetweenHttpRequests=0
### in milliseconds = max 1000 - alternate value used immediately after a block change
source.local.2.minIntervalBetweenHttpRequestsWhenFrantic=0
### max works to cache.  Server will continually poll upstream until the cache has reached this limit.
### as soon as it drops under this number it will start polling again to keep the cache full.
### work can be removed from cache either by delivering to a client or by sitting there for longer than
### maxWorkAgeToFlush
source.local.2.maxCacheSize=100
### maximum time in milliseconds to wait for the cache to return work before giving up and returning an error result.
source.local.2.cacheWaitTimeout=30000

### The following settings are only relevant to local sources:

### allow non getwork requests to be passed through to this source as a proxy.
### If true methods allowed are filtered by source.local.1.allowPassthruMethods
### getblocknumber is always allowed and returns the latest block number from any source
source.local.2.allowJSON-RPCPassthru=false

### comma delimited list of method names that are allowed to pass through.  
source.local.2.allowedPassthruMethods=

### defaults to min difficulty: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
### don't know why you'd want different difficulty per source but it's there if you need it.
#source.local.2.rewriteDifficultyTarget=ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000

###default true = set to false if you want to PoolServerJ as a proxy for non-pool mining
#source.local.2.rewriteDifficulty=false

Oh Yes ... Sorry Shads ,

poolserverj didnt starting with Testnet again. 
If i work without testnet there are all without error`s ... 

[code][24:51:47.071] user.dir: /home/smart/Downloads/poolserverj-0.4.0rc2/bin
[24:51:47.076] Home path set to: /home/smart/Downloads/poolserverj-0.4.0rc2/bin/poolserverj.jar
[24:51:47.076] Home directory set from jar file location to: /home/smart/Downloads/poolserverj-0.4.0rc2
[24:51:47.165] Wrote PID: 11280 to pidFile: /home/smart/Downloads/poolserverj-0.4.0rc2/tmp/poolserverj.pid
[24:51:47.351] Connecting to DB URL: jdbc:mysql://127.0.0.1:3306/test?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[24:51:48.518] Mapped parameter 1 to field 1 (remote_host)
[24:51:48.519] Mapped parameter 2 to field 2 (username)
[24:51:48.519] Mapped parameter 3 to field 3 (our_result)
[24:51:48.519] Mapped parameter 4 to field 4 (upstream_result)
[24:51:48.519] Mapped parameter 5 to field 5 (reason)
[24:51:48.519] Mapped parameter 6 to field 6 (solution)
[24:51:48.519] Mapped parameter 7 to field 7 (time)
[24:51:48.519] Mapped parameter 8 to field 8 (source)
[24:51:48.520] Mapped parameter 9 to field 9 (block_num)
[24:51:48.520] Mapped parameter 10 to field 51 (our_result_bitcoin)
[24:51:48.520] Mapped parameter 11 to field 52 (our_result_namecoin)
[24:51:48.528] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[24:51:48.529] Building Worker-authentication-engine: WorkerAuthenticator.class with extraParams: null
Failed to start
java.lang.NullPointerException
        at com.google.bitcoin.core.Base58.decodeToBigInteger(Base58.java:81)
        at com.google.bitcoin.core.Base58.decode(Base58.java:61)
        at com.google.bitcoin.core.Base58.decodeChecked(Base58.java:98)
        at com.google.bitcoin.core.VersionedChecksummedBytes.(VersionedChecksummedBytes.java:34)
        at com.google.bitcoin.core.Address.(Address.java:55)
        at com.shadworld.poolserver.conf.Conf.configureSources(Conf.java:598)
        at com.shadworld.poolserver.conf.Conf.update(Conf.java:279)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:189)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:175)
        at com.shadworld.poolserver.PoolServer.(PoolServer.java:114)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:98)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
PoolServerJ Service Finished Fri Nov 11 00:51:48 PST 2011