genau VirtualAdept...VirtualAdept hat geschrieben: Zumindest könnten sie dann mal den Client-Text nicht so "angsteinflößend" gestalten...
Code: Alles auswählen
Michael. It would be helpful if you provided at least a log associated with the problem that you refer to as a "malfunctional" database or client.
Here is a portion of your recent work log stored on our server.
5/19/2004 8:16:32 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:19:00 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:19:38 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:20:16 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:20:54 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:21:36 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
5/19/2004 8:22:14 AM <JobPacket Id="0" lLastErrorNum="-2147217871" sLastErrorDescr="Unit cached for later insertion. Error: Timeout expired" bRetry="false"></JobPacket> [758][Michael_HW_Weber] [weberm@mailer.uni-marburg.de]
Notice the Error Description: "Unit cached for later insertion......" You should find a similar message in your LM client logs as well.
There were many improvements done since your last notice that you are, obviously, not aware of. As we explained several times on our support forum: http://www.planetspectre.com/cgi-bin/lifemapper/ikonboard.cgi (we refer to this forum from our main site, you should find a great deal of information there as we do most of suppor there recently), if our servers experience problems, the uploaded units are temporarily stored in the server-side cache until they are later inserted into our database. Then they are deleted by the client so the client does not need to manage those units any longer.
Some of the forum threads touching on server-side caching:
http://planetspectre.com/cgi-bin/lifemapper/ikonboard.cgi?s=0c3e1815a138cd0cf9d0edd05ff23466;act=ST;f=1;t=287;st=0
http://planetspectre.com/cgi-bin/lifemapper/ikonboard.cgi?s=8fface4875d7e10b1d1d645d0ecec9d1;act=ST;f=2;t=20
http://planetspectre.com/cgi-bin/lifemapper/ikonboard.cgi?s=09f339f94e2cf46160c517754ce41a80;act=ST;f=10;t=373;hl=cache
You can also check the status of the server on our main site (look for Server Status button right below other buttons) or at the direct link: http://www.lifemapper.org/clientservercomm/pipelinemonitorclient/pipelinemonitorclient.aspx
It shows you the status of the cache where the units temporarily stored for later insertion.
Hopefully, this information will reduce your frustration with our periodically slow or seemingly malfunctional system. Again, be advised that completed units are NOT discarded because we understand and appreciate your energy costs associated with your DC participation.
Best wishes, LMCode: Alles auswählen
Hi,
I really would have provided a log if the client would create one. At least, I cannot find any in my LM directory - but maybe you can give me details on where to find it such that I can provide it to you. Also, I do NOT speak for myself but instead for a few hundreds of people working together with me in our dc computing team. From time to time we initiate what we call a taskforce operation. This time I suggested that LM would be a project worth receiving heavy support for a while and then these never ending bugs. And again - you can tell me what you want: At my end the client completes a work unit, tries to contact the server, cannot submit the results and then INFORMS ME THAT THE RESULT WAS DISCARDED IRREVERSIBLY WITH AN ADDITIONAL "SORRY" NOTE. If this is only a false notification, then it still is a SERIOUS bug that makes people quit the Lifemapper project - be assured of this (a number of people have left our taskforce operation already). Please provide me instructions such that I can help you solve this issue ASAP and don't forget to place a notification on your website right into the news section or wherever you might find it suitable.
And thank you for your quick reply this time (last time I waited a couple of days - our machines can't wait but rather hop to a different project if the one we are currently working on seems not worth being further supported).
:-)
Michael.
Code: Alles auswählen
Thanks, Michael, for your support.
You have a point that our main web site does not explain the late changes. In fact, being a very small project, we are doing almost all the support function through the www.planetspectre.com forum due to the convenience. Lately we just do not have much time to keep our main web site up-to-date. So, I'd advise you to visit the http://www.planetspectre.com/cgi-bin/lifemapper/ikonboard.cgi regularly and tell others to do so as well. We've been using this forum for more than a year. Most Mappers check it on regular basis.
We'll post information about caching in the Lifemapper's News section as well.
Based on your feedback, your logging is probably not enabled. For the logging, use the -l switch, as the readme file indicates: http://www.lifemapper.org/lm-downloads/bin/readme.txt . For example, "lifemapper_cmd.exe -l".
Cheers, LM
Code: Alles auswählen
"C:\Program Files\dc clients\Lifemapper CLI\lifemapper_cmd.exe" -l -p 64 -c 200 -x http://www-cache.uni-marburg.de:3128
Die nächste Version des DC Monitor (vermutlich ab Samstag zum Download) macht das automatisch, so daß man damit auf den PacketWatcher verzichten kann.maxamd400 hat geschrieben: Auch hab i im dem verzeichnis hier nun mehrere JobPacketxx.dat mit ner grösse von 180bytes rumzuliegen...
LM_Packet_Watcher.exe löscht diese aber nicht... !!!
Einfach doch per hand löschen...??
Thorsten
Code: Alles auswählen
[Fri May 21 12:26:28 2004] [2152] [1] [at UserInterface::displayError()] Could not parse job info XML text. Error message: none
[Fri May 21 12:43:48 2004] [2152] [1] [at LifemapperProcessor::loadJobFromLocalCache()] Could not parse job info XML text. Error message: none
[Fri May 21 12:43:48 2004] [2152] [1] [at UserInterface::displayError()] Could not parse job info XML text. Error message: none
[Fri May 21 14:25:44 2004] [2152] [1] [at LifemapperProcessor::loadJobFromLocalCache()] Could not parse job info XML text. Error message: none
[Fri May 21 14:25:44 2004] [2152] [1] [at UserInterface::displayError()] Could not parse job info XML text. Error message: noneCode: Alles auswählen
[Wed May 19 11:07:48 2004] [700] [1] [at LifemapperProcessor::processingLoop()] Could not rename JobPacket file "JobPacket1.dat".
[Wed May 19 11:07:48 2004] [700] [1] [at UserInterface::displayError()] Could not rename JobPacket file "JobPacket1.dat".
[Wed May 19 11:08:08 2004] [700] [1] [at LifemapperProcessor::renameFile()] Unknown reason.
Hier liegt dasselbe "Problem" vor, wie bei Seti@Home: Die Clients zählen nicht local, sondern Fragen den Server, wieviele Ergebnisse auf dem Account bereits vorliegen. Jeder der Clients zeigt daher die bisherige Gesamtzahl der WU's an. Die restlichen 60 sind die Differenz seit dem letzten Statistikupdate.Zeuge hat geschrieben:Hallo Leute
Ich habe den Clienten 3 mal mit dem gleichen Usernamen installiert bzw. am laufen.
Leider zeigt die Statistik nur ein drittel des gesamten Output an.
Jeder Client zeigt ungefähr: Number of work units completed: 491 an.
Die Lifemapper Statistik zeigt aber nur ca. 428 an.
Liegt dies event. an der mehrfachen Verwendung des Usernamen?
...zweimal täglich...
