yes I'm just working on that issue... was reported elsewhere as well..
Keep the reports coming...
http://poolserverj.org/dist/poolserverj-0.4.0rc3-mini-binary.tar.gz fixes urstroyers issue
Topic: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1 - page 6. (Read 17427 times)
When I connect one single user to it I get this error message...
I notice this on start up and just so you know I did a cURL and it worked and then I copied and pasted the username password and URL into settings file so I don't look silly once again..
not sure what I missed.
Code:
java.lang.NullPointerException
at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doRequest(AbstractJsonRpcServlet.java:138)
at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doPost(AbstractJsonRpcServlet.java:113)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
at org.eclipse.jetty.server.Server.handle(Server.java:341)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
at java.lang.Thread.run(Unknown Source)
I notice this on start up and just so you know I did a cURL and it worked and then I copied and pasted the username password and URL into settings file so I don't look silly once again..
Code:
[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY
[05:25:51.760] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.761] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.761] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.778] Updating donation target address for chain: namecoin Address: NFja75nNRHZYKtN9YQ6wHPQdmhzBEAmTAt
[05:25:51.787] Updating donation target address for chain: bitcoin Address: 1Lk8f18EyPB3uAJvgTeHgzCVkKY9njQ5bA
752 [main] INFO com.google.bitcoin.core.NetworkConnection - Connected to peer: version=32464, subVer='', services=0x1, time=Wed Nov 09 05:25:51 UTC 2011, blocks=152492
[05:25:51.788] Established outbound p2p connection to ms2.nmcbit.com:8333
[05:25:51.820] RETRY
[05:25:51.824] New Block detected [26967] from source: DaemonSource[cs40].nameco
not sure what I missed.
What is?
source.local.1.p2p.hostport
Is that for example the bitcoin p2p port people open on the firewall to get more connections like 8333 is that the port I use for that setting?
Also how come there is no setting for the Aux chain should I add one...
source.local.1.merged.namecoin.p2p.hostport
source.local.1.p2p.hostport
Is that for example the bitcoin p2p port people open on the firewall to get more connections like 8333 is that the port I use for that setting?
Also how come there is no setting for the Aux chain should I add one...
source.local.1.merged.namecoin.p2p.hostport
it's the bitcoin protocol port of yr bitcoind. For sending blocks via bitcoin protocol as a backup in case rpc craps itself.
There's no setting for aux chains as I haven't implemented it for them. I'm still thinking about whether this is really useful or not...
While running psj 0.4 under load i get spammed with those messages:
Any idea? Or more logfiles needed?
Code:
43559 [main-con-qtp-103] WARN org.eclipse.jetty.util.log - /
java.lang.NullPointerException
at com.shadworld.poolserver.WorkProxy.validateWork(WorkProxy.java:278)
at com.shadworld.poolserver.WorkProxy.handleRequest(WorkProxy.java:431)
at com.shadworld.poolserver.servlet.PoolServerJServlet.getResponse(PoolServerJServlet.java:26)
at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doRequest(AbstractJsonRpcServlet.java:255)
at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doPost(AbstractJsonRpcServlet.java:113)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1352)
at org.eclipse.jetty.servlets.QoSFilter.doFilter(QoSFilter.java:205)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
at org.eclipse.jetty.server.Server.handle(Server.java:341)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
at java.lang.Thread.run(Thread.java:662)
Any idea? Or more logfiles needed?
What is?
source.local.1.p2p.hostport
Is that for example the bitcoin p2p port people open on the firewall to get more connections like 8333 is that the port I use for that setting?
Also how come there is no setting for the Aux chain should I add one...
source.local.1.merged.namecoin.p2p.hostport
source.local.1.p2p.hostport
Is that for example the bitcoin p2p port people open on the firewall to get more connections like 8333 is that the port I use for that setting?
Also how come there is no setting for the Aux chain should I add one...
source.local.1.merged.namecoin.p2p.hostport
I have a few issues with the below query...
1. id = (?) Should it not be id IN (?) if you want to get a list of workers you some how know the id of.
2. What is this for how do you know the ids?
3. All MySQL example statements in the config files do not end with ";" can I assume we don't need it?
Code:
db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);
2. What is this for how do you know the ids?
3. All MySQL example statements in the config files do not end with ";" can I assume we don't need it?
You have a sharp eye! That's not supposed to be there. It's for a feature I've built but not yet enabled. Worker cache preloading. Basically it just does a bulk load of workers that were in the cache last time the server was shutdown. This is because the worker select process isn't really designed to be done en masse because it hardly ever needs to be but if a busy server is restarted with lots of workers connected it will start with an empty cache then get a flood of auth requests so has to do a whole heap of single selects.
1/ yes it should IN (?)
2/ psj dumps the id's to a file when it shuts down
3/ no they don't need it. The jdbc driver adds a ;
I have a few issues with the below query...
1. id = (?) Should it not be id IN (?) if you want to get a list of workers you some how know the id of.
2. What is this for how do you know the ids?
3. All MySQL example statements in the config files do not end with ";" can I assume we don't need it?
Also what is?
source.local.1.p2p.hostport
Is that for example the bitcoin port like 8333 is that the port I use?
Code:
db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);
2. What is this for how do you know the ids?
3. All MySQL example statements in the config files do not end with ";" can I assume we don't need it?
Also what is?
source.local.1.p2p.hostport
Is that for example the bitcoin port like 8333 is that the port I use?
ahh sorry, forgot to make the parent directory before creating the donation.ack file. Mine already existed so didn't catch this one. Bug fixed and commited to repo.
Pontius' workaround is correct... If the tmp/donation.ack file exists you won't ever see this message again.
rc2 is uploading now. Should be done in about 10 mins. Only difference is the above bug.
Pontius' workaround is correct... If the tmp/donation.ack file exists you won't ever see this message again.
rc2 is uploading now. Should be done in about 10 mins. Only difference is the above bug.
@urstroyer: I was too stupid to find the source code for 'com.shadworld.poolserver.conf.Conf.doDonationWarning()' at the bitbucket repo so I don't know what's happening there but good ol' strace -f -e trace=file ... helped.
Do this and psj will start.
Do this and psj will start.
Code:
mkdir /****/poolserverj-0.4.0rc1/tmp
touch /****/poolserverj-0.4.0rc1/tmp/donation.ack
Here we got! That worked, thanks a lot! <3
@urstroyer: I was too stupid to find the source code for 'com.shadworld.poolserver.conf.Conf.doDonationWarning()' at the bitbucket repo so I don't know what's happening there but good ol' strace -f -e trace=file ... helped.
Do this and psj will start.
Do this and psj will start.
Code:
mkdir /****/poolserverj-0.4.0rc1/tmp
touch /****/poolserverj-0.4.0rc1/tmp/donation.ack
This looks great. I'm definitely going to play with this over the weekend.
Maybe i did some awesome stupid while trying to start 0.4 but this is what i experienced:
Code:
/poolserverj-0.4.0rc1/bin# java -classpath poolserverj.jar:../lib/*:../lib/lib_non-maven/*:../lib/plugins com.shadworld.poolserver.servicelauncher.PoolServerService start ../conf/local-daemon-mm.properties
Args - [2]: start ../conf/local-daemon-mm.properties
PoolServerJ Service Starting Tue Nov 08 18:30:58 CET 2011
[18:30:58.816] user.dir: /****/poolserverj-0.4.0rc1/bin
[18:30:58.817] Home path set to: /****/poolserverj-0.4.0rc1/bin/poolserverj.jar
[18:30:58.817] Home directory set from jar file location to: /****/poolserverj-0.4.0rc1
#####################################################################
### PLEASE READ THIS ###
### ###
### PoolServerj contains the capability to send donations via ###
### the coinbase transaction. The provided sample properties ###
### file is configured to send a small donation to the ###
### poolserverj developer. You can remove this if you want to. ###
### ###
### This warning is intended to ensure you are aware that it ###
### exists and will not appear again once you acknowlege it. ###
### ###
### If you have read this warning and would like to continue ###
### please indicate that you agree you are aware of the default ###
### donation by typing 'I agree' at the prompt. ###
#####################################################################
Do you agree that you are aware of the default donation? : I agree
[18:31:00.969] Failed to read from console
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:883)
at com.shadworld.poolserver.conf.Conf.doDonationWarning(Conf.java:298)
at com.shadworld.poolserver.conf.Conf.update(Conf.java:263)
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:113)
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)
Quote
- adjust longpolling to account for additional chains. LP now fires when any chain finds a new block but waits until a getblocknumber has come back from each chain first to try and prevent double LPs. If a daemon is down it will timeout and fire the longpoll anyway after 1 second.
Does this change fix or reduce the number of partial-stales created by cgminer?
Quote
- adjust longpolling to account for additional chains. LP now fires when any chain finds a new block but waits until a getblocknumber has come back from each chain first to try and prevent double LPs. If a daemon is down it will timeout and fire the longpoll anyway after 1 second.
Does this change fix or reduce the number of partial-stales created by cgminer?
Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?
You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses. A 50btc+ Tx fees do not mature after 120 blocks so how are they paid to an address?
Quote
I highly recommend making this very small patch to you daemons. This simply prevents your debug.log being spammed.
Spammed by who? Users RPC calls made by users via PSJ or directly from exposed bitcoind rpc ports?spammed by psj making frequent calls to getmemorypool and getblocknumber...
A normal bitcoin block reward is payed out to an address, it just an address the daemon grabs from your wallet that you never see. A coinbased reward is the same except you specify the address from any of your own wallets (or someone else's if you feel so inclined)... It will still show up as a generation transaction and you won't be able to spend it for 120 block like any other generation transaction.
Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?
You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses. A 50btc+ Tx fees do not mature after 120 blocks so how are they paid to an address?
Quote
I highly recommend making this very small patch to you daemons. This simply prevents your debug.log being spammed.
Spammed by who? Users RPC calls made by users via PSJ or directly from exposed bitcoind rpc ports?The reason I'm suggesting this method is because I'm not convinced there's much chance of miner developers implementing an entire new protocol. We already have a binary protocol that should be reasonably easy to implement, but most miners still don't support it. (It's also probably good enough; even without differential updates and with the redundant hash1 and midstate included a getwork response easily fits uncompressed into a single packet.)
Incremental improvements to the existing JSON-RPC way of doing things seem to get a much better reception. No idea why.
Incremental improvements to the existing JSON-RPC way of doing things seem to get a much better reception. No idea why.
because it's easier I guess
I don't really go into low level network protocol much these days so I'd be interested to understand the real difference in bandwidth usage between a say a 40 byte message and 200 byte message. I know there are minimum payloads for various protocols but I don't what values for which ones. I know about jgarzik's proposal but to my knowledge there are no implementations so I think refresh of the spec to take current circumstance into account is warranted. I have always argued that everything people complain about with pushpool's design is due to the vastly different state the bitcoin community was in at the time it was design. This protocol was designed at the same time so the same applies.
I agree an RPC extension is more likely to gain quick adoption but if mm has taught me anything it's the power of demand. If demand is satisfied with a quick and dirty approach, i.e. rpc extension, then demand for a better overall solution who's benefits are more strategic will be sucked dry. I wonder if it would be better to just implement a binary protocol with no competing rpc version this creating the choice, implement binary and get benefit or don't... Vs implement binary which is a bit harder and get benefit or implement rpc which is easier and get benefit but get no closer to strategic benefit.
I was intending after discussion of protocol to implement both the PSJ side as well as reference client. This reference client could be easily ported in diablominer. And also farily easily turned into a local proxy that miners could run locally. If at least one client supports it and pools throw their weight behind it (i.e. refuse to add anymore extensions to the rpc protocol) then market forces will push other miner devs to adopt.
Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?
'coinbasing' or 'coinbaser' as a verb was probably invented by luke-jr. It simply means creating or controlling the coinbase transaction. Every block has 1 or more transactions. Every transaction must reference previous transactions to show where the coins came from (the inputs). The first transaction in the block (the coinbase transaction) has special rules and doesn't need an input. This is where the 50btc reward from finding a block comes from. When you getwork from a bitcoin daemon the coinbase transaction is generated inside the daemon so you can't do anything out of the ordinary with it. It simply pays out 50btc to an address that belongs to the bitcoin wallet that the bitcoin daemon is using. When you generate the coinbase yourself you are replicating what the daemon does but you can do it differently. You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses. As long as you don't break these rules the block is valid and will be accepted by any bitcoin node. In fact you don't even need to submit a winning block to your local bitcoin daemon. You could submit it to any daemon with the getmemorypool patch or you could just broadcast it on the bitcoin p2p network. PSJ actually does this as a backup, it sends getmemorypool then it sends via a p2p connection to the same node using the bitcoin protocol. This is an experimental feature which I've actually seen working a few times, the p2p broadcast was accepted first so the getmemorypool submit was rejected because the block had already been received. This can potentially be extended in future so that PSJ connects to many bitcoin nodes on p2p and broadcasts directly to get the block propagated as quickly as possible and reduce the chance of it conflicting with another block from another miner/pool.
Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?
Though it would require miner support. And if I'm going to go down the road of cajoling miner devs to support another protocol adjustment I wonder I should just exert the effort getting uptake for a differential binary protocol... I'm going to post a proposed spec for discussion in the next few days. The spec I have in mind would eliminate the need for LP requests altogether.
The reason I'm suggesting this method is because I'm not convinced there's much chance of miner developers implementing an entire new protocol. We already have a binary protocol that should be reasonably easy to implement, but most miners still don't support it. (It's also probably good enough; even without differential updates and with the redundant hash1 and midstate included a getwork response easily fits uncompressed into a single packet.)Incremental improvements to the existing JSON-RPC way of doing things seem to get a much better reception. No idea why.
Jump to: