Great!
After many delays, including the failure of this forum, I can finally announce the completion of SBQueue v0.20 alpha. Changes include numerous bugfixes, a simplified command-line switch structure, and the much-requested auto flush option.
Now everybody download it from the link in my signature, and let me know what bugs I missed.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
Great!
I have noticed that when "Auto transmit Blocks" is activated, SBQueue no longer works as a server but as thruport. This gives a decrease of production of blocks if the sb.pns.net server is busy like wise the client standalone normaly has.
As it was intended. But it should still serve new work from the local queue(s).Originally posted by Joh14vers6
I have noticed that when "Auto transmit Blocks" is activated, SBQueue no longer works as a server but as thruport.Huh? You mean something like the proxy freezes when it can't connect?This gives a decrease of production of blocks if the sb.pns.net server is busy like wise the client standalone normaly has.
Anybody else here speak Dutch who can help translate?
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
That is happening also (with manual submitting blocks), but that is not what I mean here.Originally posted by Ken_g6[TA]
Huh? You mean something like the proxy freezes when it can't connect?
When the client sends a block to the server, it waits an amount of time until the server reports back that the block can be sended or exceeds the timelimit of the connection. When the client is waiting for connection, he is not producing work. That 's how the SoB-client behave when it directly submit blocks to the server and also with SBQueue as thru port. This is not an error, but a disadvantage. I mainly use SBQueue as a separate transmitter of test/blocks so the the client is not disturbed by transmitting problems.
OK I have to improve my English.
I don't think so - it's just that we were not able to follow your thoughts...Originally posted by Joh14vers6
OK I have to improve my English.
Perhaps an option like 'automatically transmit work after x days' would fix the problem?
The new version looks good, Ken
I don't see how that option would help me follow Joh14vers6's thoughts.
Actually, I'm going to try adding a new thread for flushing. There's no reason why any client should freeze while sending intermediate results, except that writing threads can be messy in C.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
Very nice job. one request would be to save settings to a config file somewhere. it's a mild nuisance to have to start the server and set auto-flush every time I start the program.
cheers,
Marc
You realize you can do that with:
java -jar SBQueue.jar -gst
I suppose I could make a file that you put "-gst" in that would append it to the command string, if you really want a file.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
aha it appears I forgot to read the readme file.
I installed SBqueue yesterday and it has crashed 2 time. Well it doesnot crash, it hangs. The last thing it says is:
Connecting to server...
The first time I was a bit inpatient and restarted the SBqueue within a few minutes. But During the night it hung for a almost 9 hours.
Anyone got an idea what might be wrong?
I'm running SBqueue on my linux server. I know the readme said that it was tested on a windows machine. But Java should be cross platform so I gave it a try and worked.
I start the SBqueue like this:
/usr/java/j2re1.4.1_02/bin/java -jar ./SBQueue.jar -str
----
Edit:
Look what I just saw:
[Tue Apr 20 10:31:02 CEST 2004] Connection received from /xxx.xxx.xxx.xxx
Error reading stream.
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:397)
at SBString.myRead(SBString.java:53)
at SBString.<init>(SBString.java:47)
at SBVector.<init>(SBVector.java:38)
at SBProxy.run(SBProxy.java:117)
at SBMain.main(SBMain.java:156)
[Tue Apr 20 10:33:48 CEST 2004] Connection received from /yyy.yyy.yyy.yyy
----
Edit2:
I just wrote a nasty restart script wich kills all my java threads (I'm not running any java apps besides the SBqueue). Dont know how well the proxy handels with a kill signal when it is communicating with a client or the server.... But since I only run it once a day I think the risc will not be that great.
Last edited by Haranaka; 04-20-2004 at 07:46 PM.
As I said in an earlier post, I need to add a separate thread for flushing. I actually have something written up, but multithreading is always tricky. This suggests to me that a new flush request should interrupt an old flush request. It's next on my todo for SBQueue, but I've been doing more job searching lately.The first time I was a bit inpatient and restarted the SBqueue within a few minutes. But During the night it hung for a almost 9 hours.
Anyone got an idea what might be wrong?
P.S. I think it hung this time because the main server was hanging.
This looks like an error occurred on the client side. Have you looked at the client's logs?Look what I just saw:
[Tue Apr 20 10:31:02 CEST 2004] Connection received from /xxx.xxx.xxx.xxx
Error reading stream.
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:397)
I don't think this should be a problem. Are you doing this for the hanging thing?I just wrote a nasty restart script wich kills all my java threads...
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
well, now I'm trying to test this.
java take 28Mb of memory =(( why the hell I don't know asm?
looks like it works! OMG 50 boxens waiting!!!
so theres a few questions. can queue automatically fetch needed jobs? and is there any logs?
and when i run queue form cmd cmd becomes unresponsible. when i run it from "run..." from start butoon, there's also exist java windows with queue window.
oops like i can get rid of this by using javaw.
The SBqueue hung again last night, and the client on my workstation was done with a test and wanted a new test. So the another couple of hours of CPU time wasted... well thats all in the game, no blame towards any of you.Originally posted by Ken_g6[TA]
As I said in an earlier post, I need to add a separate thread for flushing. I actually have something written up, but multithreading is always tricky. This suggests to me that a new flush request should interrupt an old flush request. It's next on my todo for SBQueue, but I've been doing more job searching lately.
P.S. I think it hung this time because the main server was hanging.
This looks like an error occurred on the client side. Have you looked at the client's logs?
I don't think this should be a problem. Are you doing this for the hanging thing?
I think I'm not going to use the auto submit function, so the SBqueue does not have to contact the server as much as before, in hope that it will hang less often.
The restart script was indeed for handeling a hung SQqueue, first kill all java threads, then wait 30 sec, then start the SBqueue again.
Jobs will be fetched, but only when the queue runs out of jobs. I'm planning to change that in a version or two. I've never created logs, since no one asked. Are you asking for logs?Originally posted by Death
[B]well, now I'm trying to test this.
java take 28Mb of memory =(( why the hell I don't know asm?
looks like it works! OMG 50 boxens waiting!!!
so theres a few questions. can queue automatically fetch needed jobs? and is there any logs?
P.S. The Queue is likely to freeze when using auto-reporting ATM (at the moment), in case you haven't read this above.
Last edited by Ken_g6[TA]; 04-29-2004 at 11:01 AM.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
Originally posted by Ken_g6[TA]
Jobs will be fetched, but only when the queue runs out of jobs. I'm planning to change that in a version or two. I've never created logs, since no one asked. Are you asking for logs?
P.S. The Queue is likely to freeze when using auto-reporting ATM, in case you haven't read this above.
what is ATM?
ATM => Auto Transmit Blocks
Association of Teachers of Mathematics
I always thought ATM was a hole in the wall that you can get money from
But I think in this case Ken means At The Moment
Adobe Type Manager
http://www.adobe.com/support/downloa...form=Macintosh
How about Asynchronous Transfer Mode?
I think this TLA is overdefined...
P.S.:
TLA = Three Letter Acronym
Asynchronous Transfer Mode, not Automatic Teller Machine
http://dast.nlanr.net/Glossary.html