Testing....

[mdettweiler]

Originally Posted by kar_bon

ok, here is the WIN-version of the local server/client with the above changes in the do.bat and a knpair-file in the server for testing.

how to:
- start the server by calling 'llrserver' (in folder LLRnet_server)
- start 'do.bat' (in folder LLRnet_client)
- let cllr do 5 pairs first and another 2
- stop the client with CTRL-C
- call 'do -c'
- stop server
- call 'simplify.bat' (in folder LLRnet_server)

check all files (server-result, job/knpair-files, client results) for completeness!

Quick question: how is one supposed to check to see if a pair's been canceled when running simplify.bat at the end triggers a prune? That pretty much always removes any "canceled" records from joblist.txt--after all, there's no reason for the server to keep those around since there's no reservation whatsoever on the pair. I suppose one could just verify that no active reservation is still in place, but wouldn't it be easier to just search for all instances of the pair in question in joblist.txt and see what it's latest state is (reserved, canceled, or done)?

[kar_bon]

the simplify.bat is only for persons running a server, not for 'normal' users doing work for NPLB.

so how it works now? if a pair is cancelled by a user, will the server instantly submit it to the next user requesting new pairs? could you determine this, please.

all submitted results in the result-file of the server (nothing lost), all not-done pairs are still in the knpairs.txt of the server (nothing lost, too) and the CANCEL-pairs in the joblist should be eliminated when jobMaxTime is over. or not?

i'll try this by setting the jobMaxTime to a small value and try to connect with another user, do work and submit pairs.

[mdettweiler]

Originally Posted by kar_bon

the simplify.bat is only for persons running a server, not for 'normal' users doing work for NPLB.

so how it works now? if a pair is cancelled by a user, will the server instantly submit it to the next user requesting new pairs? could you determine this, please.

all submitted results in the result-file of the server (nothing lost), all not-done pairs are still in the knpairs.txt of the server (nothing lost, too) and the CANCEL-pairs in the joblist should be eliminated when jobMaxTime is over. or not?

i'll try this by setting the jobMaxTime to a small value and try to connect with another user, do work and submit pairs.

Here's what happens:

-A pair is reserved and a notation of such is made in joblist.txt
-The same pair is canceled, and an additional notation is made in joblist.txt recording that. Note that both the reservation and cancellation joblist entries coexist, but the cancellation takes precedence since it has a newer timestamp.
-The pair is now considered immediately available for assignment just as if it was brand new.
-When the server does its next prune, it will remove both the reservation and cancellation records from joblist, since the latter negates the former and the pair is "good as new".

[kar_bon]

i've tested more with that new version:
- all pairs done without stopping the script with CTRL-C
- script stopped and continued later
- script stopped, some pairs cancelled and continued
- script stopped, some pairs cancelled and continued with other user

all is ok as i can say now.
the only thing, that should be done on the server-side when dried is, calling 2 times "llrserver -s" to clear knpairs and joblist files!

so this is it! (only speak for WIN)
without processing a workfile (which pairs done and which to cancel) and without any 'empty' line!

i've uploaded the latest V7-Version to the former link (small change in do.bat)

[mdettweiler]

Originally Posted by kar_bon

i've tested more with that new version:
- all pairs done without stopping the script with CTRL-C
- script stopped and continued later
- script stopped, some pairs cancelled and continued
- script stopped, some pairs cancelled and continued with other user

all is ok as i can say now.
the only thing, that should be done on the server-side when dried is, calling 2 times "llrserver -s" to clear knpairs and joblist files!

so this is it! (only speak for WIN)
without processing a workfile (which pairs done and which to cancel) and without any 'empty' line!

i've uploaded the latest V7-Version to the former link (small change in do.bat)

Karsten, could you possibly re-post the link? I can't find it; I tried the one in the first post of this thread but got version 0.63.

[kar_bon]

see post #198!

[mdettweiler]

Originally Posted by kar_bon

see post #198!

Ah, thanks, got it now.

[mdettweiler]

Okay, I tried testing the latest do.bat to cancel pairs, and it seems to have messed up somewhat. I tried it with 4 completed results and one incomplete test in queue, and it produced this output:

+-------------------------------------+
| LLRnet client V0.9b7 with cLLR V3.8 |
| K.Bonath, 2010-02-10, Version 0.7   |
+-------------------------------------+
Current configuration:
server = "nplb-gb1.no-ip.org"
port = 1764
username = "mdettweiler"
WUCacheSize = 5
[2010-03-05 12:58:24]
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
Cancelling : 197/118072 (600000000000:M:1:2:258)
Could Not Find C:\Documents and Settings\All Users\Documents\prime\NPLB-llrnetnew\workfile
.res
[2010-03-05 12:58:26]
  Fetching WU #5/5: 197 118072
Cancelling : 197/118094 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118102 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118142 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118154 (600000000000:M:1:2:258)
[2010-03-05 12:58:29]
Cancelling : 197/118072 (600000000000:M:1:2:258)
[2010-03-05 12:58:29]
No more job to cancel !
All jobs canceled!

First of all, all four completed results are apparently sent but rejected. (I see that there's 8 rejected messages, but that's to be expected since LLRnet's duplicated those messages on the console for as long as I can remember; also as expected, only 4 rejected messages were shown in lresults_hist.txt.) After that, all five jobs were canceled, which I verified on the server was done correctly. The program beeped a few times then exited.

So it seems the cancellation part itself is working all right; the only problem is in sending the completed results before canceling the rest. Any idea why this isn't working? I looked in do.bat but couldn't find anything that could be a culprit, since it appeared that it was doing it in a pretty straightforward way: convert the results, add them to lresults_hist.txt, then run LLRnet to send them.

[kar_bon]

ok, forgot to copy/create the workfile.bak in the cancel-routine!

update do.bat with one line:

:jobcancel

if not exist lresults.txt goto jobcancel1
copy workfile.txt workfile.bak
gawk -f do_tosend.awk lresults.txt

i'll upload the corrected zip immediately!

don't forget to call twice 'llrserver -s' after cancelling with 'do -c'!

[mdettweiler]

Originally Posted by kar_bon

ok, forgot to copy/create the workfile.bak in the cancel-routine!

update do.bat with one line:

:jobcancel
 
if not exist lresults.txt goto jobcancel1
copy workfile.txt workfile.bak
gawk -f do_tosend.awk lresults.txt

i'll upload the corrected zip immediately!

don't forget to call twice 'llrserver -s' after cancelling with 'do -c'!

Thanks! I'll give it a whirl.

[mdettweiler]

Okay, I tried it in the exact same situation as before (4 pairs done, 1 pair in progress) and it seems to have worked correctly:

+-------------------------------------+
| LLRnet client V0.9b7 with cLLR V3.8 |
| K.Bonath, 2010-02-10, Version 0.7   |
+-------------------------------------+
Current configuration:
server = "nplb-gb1.no-ip.org"
port = 1764
username = "mdettweiler"
WUCacheSize = 5
        1 file(s) copied.
[2010-03-05 13:53:57]
Cancelling : 197/121718 (600000000000:M:1:2:258)
[2010-03-05 13:53:58]
Cancelling : 197/121768 (600000000000:M:1:2:258)
[2010-03-05 13:53:58]
Cancelling : 197/121772 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
Cancelling : 197/121784 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
Cancelling : 197/121846 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
No more job to cancel !
All jobs canceled!

The only possible issue I found is a cosmetic one: after the four completed pairs are submitted, all five are then canceled despite there only being one left that's incomplete. Of course the server ignores the cancel requests on the first four since it already has results for them, but still, it might prove rather confusing for users.

The tricky part is how to have the batch file "know" how many WUs were completed and sent in. In do.pl that's done by incrementing a $numResults variable as each result is processed, but that would be impossible for do.bat since it doesn't actually do the processing but rather has gawk do it. Oh, I know! What if you had do.bat count the number of lines in tosend.txt before that's sent? If you take that number minus one (the newline at the end) it should give you the number of completed results done, and from there you can have it remove those from workfile.txt before beginning the actual cancellation process.

Edit: scratch that, looks like it didn't work. I just started up the client again and it grabbed exactly the same 5 pairs that it did before--including the ones that were already done. It seems the server didn't ignore the cancellation requests on the completed ones as I thought; somehow they were thrown back into the pool to be reassigned.

The fix would be the same as the one I presented above: the only difference being that it's no longer just a cosmetic issue but a real one.