SBQueue 0.20a is out!

[Ken_g6[TA]]

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.

[refic]

Great!

[Joh14vers6]

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.

[Ken_g6[TA]]

Originally posted by Joh14vers6
I have noticed that when "Auto transmit Blocks" is activated, SBQueue no longer works as a server but as thruport.

As it was intended. But it should still serve new work from the local queue(s).

This gives a decrease of production of blocks if the sb.pns.net server is busy like wise the client standalone normaly has.

Huh? You mean something like the proxy freezes when it can't connect?

Anybody else here speak Dutch who can help translate?

[Joh14vers6]

Originally posted by Ken_g6[TA]
Huh? You mean something like the proxy freezes when it can't connect?

That is happening also (with manual submitting blocks), but that is not what I mean here.

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.

[Mystwalker]

Originally posted by Joh14vers6
OK I have to improve my English.

I don't think so - it's just that we were not able to follow your thoughts...

[allio]

Perhaps an option like 'automatically transmit work after x days' would fix the problem?

The new version looks good, Ken

[Ken_g6[TA]]

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.

[Cmarc]

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

[Ken_g6[TA]]

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.

[Cmarc]

aha it appears I forgot to read the readme file.

[Haranaka]

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.

[Ken_g6[TA]]

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?

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.

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)

This looks like an error occurred on the client side. Have you looked at the client's logs?

I just wrote a nasty restart script wich kills all my java threads...

I don't think this should be a problem. Are you doing this for the hanging thing?

[Death]

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.

[Haranaka]

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?

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.

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.

[Ken_g6[TA]]

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?

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 (at the moment), in case you haven't read this above.

[Death]

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?

[Joh14vers6]

ATM => Auto Transmit Blocks

Association of Teachers of Mathematics

[Sunnyboy]

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

[Death]

Adobe Type Manager

http://www.adobe.com/support/downloa...form=Macintosh

[Mystwalker]

How about Asynchronous Transfer Mode?

I think this TLA is overdefined...

P.S.:
TLA = Three Letter Acronym

[Death]

Asynchronous Transfer Mode, not Automatic Teller Machine
http://dast.nlanr.net/Glossary.html