From: SourceForge.net <no...@so...> - 2008-11-17 06:51:56
|
Bugs item #2303747, was opened at 2008-11-17 07:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Nobody/Anonymous (nobody) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2008-12-30 19:01:04
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Nobody/Anonymous (nobody) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2008-12-30 19:16:15
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Nobody/Anonymous (nobody) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2009-02-14 16:27:31
|
Bugs item #2303747, was opened at 2008-11-17 00:51 Message generated for change (Comment added) made by mharsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Nobody/Anonymous (nobody) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 10:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 13:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 13:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2009-11-08 20:57:36
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Nobody/Anonymous (nobody) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2009-11-08 21:08:40
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: External Functions >Group: Next Release >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) >Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 13:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2009-11-09 00:49:44
|
Bugs item #2303747, was opened at 2008-11-17 06:51 Message generated for change (Comment added) made by jeremynicoll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions Group: Next Release Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- Comment By: Jeremy C B Nicoll (jeremynicoll) Date: 2009-11-09 00:49 Message: I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray! However I then tried out some of the supplied sample execs: a) samples\oodialog\dlgAreaDemo.rex - was sluggish responding to a click on its OK button, the first time I tried it. On subsequent runs it was sometimes fine and sometimes slow, but never dire. b) samples\oodialog\ftype.rex - every time I run this as soon as the dialog box appears asking me to choose one or other option, cpu% climbs to 100%, taking 2-3 seconds to do so. CPU use is split between 'System' at 45-50%, rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which I think is the internet traffic monitor for Zone Alarm Pro) at around 30-40%. I don't know why vsmon gets busy, not least because as soon as ftype.rex is stopped, vsmon.exe loses interest... c) samples\oodialog\calculator.rex - like ftype.rex, cpu hits 100% as soon as dialog is displayed Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too? There are also copies in \samples\oodialog\source. As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 21:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 20:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 16:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 19:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 19:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2009-11-09 01:24:54
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions Group: Next Release Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 17:24 Message: Okay, thanks a lot Jeremy. The extra copies of the OOD*.cls files in the samples directory is a hold over from the IBM Object Rexx distribution. A few months ago I made a change to the packager so that the distribution will no longer contain those extra files. ---------------------------------------------------------------------- Comment By: Jeremy C B Nicoll (jeremynicoll) Date: 2009-11-08 16:49 Message: I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray! However I then tried out some of the supplied sample execs: a) samples\oodialog\dlgAreaDemo.rex - was sluggish responding to a click on its OK button, the first time I tried it. On subsequent runs it was sometimes fine and sometimes slow, but never dire. b) samples\oodialog\ftype.rex - every time I run this as soon as the dialog box appears asking me to choose one or other option, cpu% climbs to 100%, taking 2-3 seconds to do so. CPU use is split between 'System' at 45-50%, rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which I think is the internet traffic monitor for Zone Alarm Pro) at around 30-40%. I don't know why vsmon gets busy, not least because as soon as ftype.rex is stopped, vsmon.exe loses interest... c) samples\oodialog\calculator.rex - like ftype.rex, cpu hits 100% as soon as dialog is displayed Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too? There are also copies in \samples\oodialog\source. As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 13:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2010-02-27 17:15:12
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions >Group: v4.1 Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-27 09:15 Message: The fix for this will have to come in a release after 4.0.1 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 17:24 Message: Okay, thanks a lot Jeremy. The extra copies of the OOD*.cls files in the samples directory is a hold over from the IBM Object Rexx distribution. A few months ago I made a change to the packager so that the distribution will no longer contain those extra files. ---------------------------------------------------------------------- Comment By: Jeremy C B Nicoll (jeremynicoll) Date: 2009-11-08 16:49 Message: I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray! However I then tried out some of the supplied sample execs: a) samples\oodialog\dlgAreaDemo.rex - was sluggish responding to a click on its OK button, the first time I tried it. On subsequent runs it was sometimes fine and sometimes slow, but never dire. b) samples\oodialog\ftype.rex - every time I run this as soon as the dialog box appears asking me to choose one or other option, cpu% climbs to 100%, taking 2-3 seconds to do so. CPU use is split between 'System' at 45-50%, rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which I think is the internet traffic monitor for Zone Alarm Pro) at around 30-40%. I don't know why vsmon gets busy, not least because as soon as ftype.rex is stopped, vsmon.exe loses interest... c) samples\oodialog\calculator.rex - like ftype.rex, cpu hits 100% as soon as dialog is displayed Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too? There are also copies in \samples\oodialog\source. As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 13:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2010-02-28 20:20:29
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions >Group: v4.0.1 Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-28 12:20 Message: Committed revision 5658. 4.0.1 merge. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-27 09:15 Message: The fix for this will have to come in a release after 4.0.1 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 17:24 Message: Okay, thanks a lot Jeremy. The extra copies of the OOD*.cls files in the samples directory is a hold over from the IBM Object Rexx distribution. A few months ago I made a change to the packager so that the distribution will no longer contain those extra files. ---------------------------------------------------------------------- Comment By: Jeremy C B Nicoll (jeremynicoll) Date: 2009-11-08 16:49 Message: I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray! However I then tried out some of the supplied sample execs: a) samples\oodialog\dlgAreaDemo.rex - was sluggish responding to a click on its OK button, the first time I tried it. On subsequent runs it was sometimes fine and sometimes slow, but never dire. b) samples\oodialog\ftype.rex - every time I run this as soon as the dialog box appears asking me to choose one or other option, cpu% climbs to 100%, taking 2-3 seconds to do so. CPU use is split between 'System' at 45-50%, rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which I think is the internet traffic monitor for Zone Alarm Pro) at around 30-40%. I don't know why vsmon gets busy, not least because as soon as ftype.rex is stopped, vsmon.exe loses interest... c) samples\oodialog\calculator.rex - like ftype.rex, cpu hits 100% as soon as dialog is displayed Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too? There are also copies in \samples\oodialog\source. As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 13:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |
From: SourceForge.net <no...@so...> - 2010-08-23 03:29:29
|
Bugs item #2303747, was opened at 2008-11-16 22:51 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions Group: v4.0.1 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: CPU LOAD 100% Initial Comment: An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog. After stop and restart of the application all works fine again and the cpu load is 00% . Until know we were not able to identify the reason for that behavior. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-22 20:29 Message: The fix for this item was in the 4.0.1 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-28 12:20 Message: Committed revision 5658. 4.0.1 merge. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-27 09:15 Message: The fix for this will have to come in a release after 4.0.1 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 17:24 Message: Okay, thanks a lot Jeremy. The extra copies of the OOD*.cls files in the samples directory is a hold over from the IBM Object Rexx distribution. A few months ago I made a change to the packager so that the distribution will no longer contain those extra files. ---------------------------------------------------------------------- Comment By: Jeremy C B Nicoll (jeremynicoll) Date: 2009-11-08 16:49 Message: I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray! However I then tried out some of the supplied sample execs: a) samples\oodialog\dlgAreaDemo.rex - was sluggish responding to a click on its OK button, the first time I tried it. On subsequent runs it was sometimes fine and sometimes slow, but never dire. b) samples\oodialog\ftype.rex - every time I run this as soon as the dialog box appears asking me to choose one or other option, cpu% climbs to 100%, taking 2-3 seconds to do so. CPU use is split between 'System' at 45-50%, rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which I think is the internet traffic monitor for Zone Alarm Pro) at around 30-40%. I don't know why vsmon gets busy, not least because as soon as ftype.rex is stopped, vsmon.exe loses interest... c) samples\oodialog\calculator.rex - like ftype.rex, cpu hits 100% as soon as dialog is displayed Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too? There are also copies in \samples\oodialog\source. As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 13:08 Message: Committed revision 5312. I believe this commit fixes the 100% CPU problem. The fix will be in the next release It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach. There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0. Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD*.cls files in your ooRexx installation then copy the OOD*.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory. Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-11-08 12:57 Message: Hi Mark, i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog(). You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix. ---------------------------------------------------------------------- Comment By: Mark Harsen (mharsen) Date: 2009-02-14 08:27 Message: I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread. I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:16 Message: Hi Martin, There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please. 1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.) Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways? 2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts? 3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware? ------------------------------- Can you please try these things: A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening. B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away. In the batch file the command should look like this: START "CallSearch" /D ".\" rexx ".\CallSearch" In the rexx program the code should look like this: 'START "CallSearch" /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms Thanks. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-12-30 11:00 Message: Martin, There is not much I can do about this, since I can not reproduce it. I'm going to paste in a little information here from our e-mail conversations. Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program. The batch file has this code: START "CallSearch" /B /D ".\" rexx ".\CallSearch" EXIT The other Rexx program uses essentially the same command: /*--------------------------------------------------------------------*/ /* Start the CallSearch Module */ /*--------------------------------------------------------------------*/ 'START "CallSearch" /B /D ".\"' , 'REXX ".\CallSearch"' , Callsearch_Parms >From Martin: "today I got an information from one of our users. He told me that the program was started at 10am and during lunch the screen saved has been started. after stopping screen saver the program still works fine. at 4pm the guys had a coffee brake and again the screen saver starts, When they come back, the CPU for the REXX.Exe has 70%. The User has killed the rexx session and all works fine." >From Martin: "I got again some information from the users, but I think this doesn't really help to find the problem. The problem occures always with the same rexx program (we are using 3 different) but this program runs the whole day the other one is started and closed several times a day." >From Martin: "Furthermore the problem may hw-related. Users that complains, uses a T41&T42 Think pad, user that have a T6* TP does not complain about that...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2303747&group_id=119701 |