Upload handler missing. |
Message boards : Bug reports : Upload handler missing.
Previous · 1 · 2
Author | Message |
---|---|
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
OK, many thanks for your help. If the problem comes from the proxy, then you should pardon the work I've done to you. Ok I'll check the http logs again. Perhaps there is something I can do to prevent the proxies from caching or mishandling upload handler requests. Maybe it's possible to set 'private' or 'no-cache' flags for the upload handler, so they'll use always-direct automatically. I'll have to read the http RFCs. It would be nice to have some traffic captured, with all the headers and data - perhaps the answer is there, but I don't know if BOINC can capture anything else than it already shows in the log. M4 Project homepage M4 Project wiki |
Grubix Send message Joined: 20 Jul 08 Posts: 44 Credit: 6,270,837 RAC: 0 |
You DO have permission to be running BOINC on these computers, don't you? Yes. The computers are my property, I can do with it what I want. :-) Only the proxy does not belong to me. Before you ask, I have permission to use the proxy, the access to the Internet here is a bit complicated... :-( Thanks for the worried you have done. ;-) ----------------------------- TJM, I took a computer home with me. I connected it to my home DSL access (without proxy). I got the same error (Project file upload handler is missing), so the problem does not lie in the proxy. Good news for me, bad for you. ;-) I would say we wait until all my computers are reset. And then we'll see what happens. Bye, Grubix. |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
Could you then post all the pending result names ? Or even better, compress all the pending files and upload them somewhere ? I'll then try to recreate this problem locally by trying to POST the content directly to upload handler. M4 Project homepage M4 Project wiki |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
I got your mail, everything I need is there (ignore my first reply where I said that files are missing, I don't need them anyway). I'm preparing an upgrade of file_upload_handler to revision 19050 - I suspect the one I use now might have a weird bug which causes random problems like this. I'm not 100% sure if there's a bug (there are strange entries in the log and at least two of your workunits are listed there), but trying to switch to newer version won't hurt and won't take much time, if anything goes wrong rolling back to the old one will take less than 5 minutes. M4 Project homepage M4 Project wiki |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
I've just finished upgrading, both scheduler and file_upload_handler are now from the highest revision compatible with my database. M4 Project homepage M4 Project wiki |
Grubix Send message Joined: 20 Jul 08 Posts: 44 Credit: 6,270,837 RAC: 0 |
I tried it just now, but it does not work. Should I abort the WUs and see if happens again in the future? |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
No, just keep them as long as you can - these workunits are now useful for debugging. Btw, are you sure that the PC you used at home (the one I received data files from) didn't connect via proxy ? The client_state says that proxy is configured, and M4 Project homepage M4 Project wiki |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
Perhaps this is a weird bug in the file upload handler. These files are already on the server inside upload folder, but the file upload handler does't see them and returns 0 for their size. M4 Project homepage M4 Project wiki |
Grubix Send message Joined: 20 Jul 08 Posts: 44 Credit: 6,270,837 RAC: 0 |
No, just keep them as long as you can - these workunits are now useful for debugging. OK, no problem. I'll help you gladly with all tests I should do. You should endure only my English more. ;-) Btw, are you sure that the PC you used at home (the one I received data files from) didn't connect via proxy ? Yes, but I did it only when I wrote it to you. Then I went back through the proxy. The client_state says that proxy is configured, and <no_proxy></no_proxy> is not set, so I guess it will try to use the same proxy settings that you use at work (if it allows connecting from outside). When I copied the data for you, I had re-configured the computer to use the proxy. I can also access the proxy from home. It is provided so. |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
I think that the problem is fixed for all workunits generated after 23:30 my time. I had to switch back to old work unit names (digits only in workunit ID). It looks like upload handler has some unexplained problems handling mixed case filenames. During the next few days we'll see if that solved the problem. I'm not sure if it's possible to fix the existing uploads, perhaps removing and adding (the BOINC has to be stopped while doing this) for each result will do the trick and the client will report the results - the output files are on the server already, just the client doesn't know about it. M4 Project homepage M4 Project wiki |
Grubix Send message Joined: 20 Jul 08 Posts: 44 Credit: 6,270,837 RAC: 0 |
I'm not sure if it's possible to fix the existing uploads, perhaps removing ... and adding ... The trick worked: After some minutes, the server shows this: That is no problem for me. Much more important is that we have found this "Project file upload handler is missing" bug (perhaps, i hope). Till now, I have been used the trick in these WUs: awgly100_0_ ADBD, ADCl, ADDA, ADGi and awgly100_0_ADGu_0 For the WUs awgly100_0_yRCq_0_0_0 and awgly100_0_yRzk_0_0_0 it was too late, they had already disappeared with the message "giving up ...". On Monday (possibly not until Tuesday) I'll try it with the other computers. I wish you a good week, Grubix. |
TJM Project administrator Project developer Project scientist Send message Joined: 25 Aug 07 Posts: 843 Credit: 267,994,998 RAC: 0 |
Step 2 validator probably found that something was wrong, so it marked the workunits to be resend, but these results were accepted and credits were granted. M4 Project homepage M4 Project wiki |
Grubix Send message Joined: 20 Jul 08 Posts: 44 Credit: 6,270,837 RAC: 0 |
I am currently trying to provoke the error. After the WU was sent, I interrupt the connection before I receive the server response. Thus, the WU has been received at the server, but my client wants to send them again. Now I wait a few minutes. Then I set the internet up again, and the client wants to send the WU again. After the request, I now get immediately the answer, that the WU is already recieved. So far, everything looks good, i can't provoke an error. Bye, Grubix. |
Message boards :
Bug reports :
Upload handler missing.