Menu
▾
▴
htmlunit-develop
|
From: Brad C. <br...@br...> - 2009-03-02 17:00:20
|
The new JS job manager is causing us some major problems. I've tried to isolate the problem and could not. I've tried to make it better while still using the executor but could not fix everything I was seeing. I'm about to have to take it out and try it with the old job management but with the rest of post-2.4 changes in place so I'm just getting the refactorings and simple changes I've made checked in without any of the job management changes. I didn't write tests for the window closing stuff because it was just something I happened to do while trying to fix the job management. It might be testable but it's more about cleaning up properly than any functional changes so I didn't spend any time writing tests. Right now I'm thinking about making the job manager pluggable so both versions can exist. I think this will be needed long-term anyway since the last time I checked Firefox and IE did things somewhat differently. May not matter any time soon since to get to a true browser-like model we'd have to have all JS running on a thread instead of in the main thread. This might mean that WebClient.waitForJobsWithinDelayToFinish will have to go away for a while since the old version didn't have this feature. On the plus side, we'll get a job manager that's really unit testable, which should make adding it back in much easier. Thoughts? Brad C |
|
From: Daniel G. <djg...@gm...> - 2009-03-02 19:25:16
|
Hi Brad, > The new JS job manager is causing us some major problems. Can you write some unit tests for them, so that we can see what you're seeing? > Right now I'm thinking about making the job manager pluggable so both versions can exist. Should be easy, just implement the JavaScriptJobManager interface to your liking (and use your impl rather than the default impl). > I'm about to have to take it out and try it with the old job management If you're talking about committing this change, I couldn't disagree more. If you're talking about a local change, that's fine. But it seems like a drastic measure given that all of our unit tests are passing. See my comment to item 1 above. Take care, Daniel On Mon, Mar 2, 2009 at 12:00 PM, Brad Clarke <br...@br...> wrote: > The new JS job manager is causing us some major problems. I've tried > to isolate the problem and could not. I've tried to make it better > while still using the executor but could not fix everything I was > seeing. I'm about to have to take it out and try it with the old job > management but with the rest of post-2.4 changes in place so I'm just > getting the refactorings and simple changes I've made checked in > without any of the job management changes. I didn't write tests for > the window closing stuff because it was just something I happened to > do while trying to fix the job management. It might be testable but > it's more about cleaning up properly than any functional changes so I > didn't spend any time writing tests. > > Right now I'm thinking about making the job manager pluggable so both > versions can exist. I think this will be needed long-term anyway since > the last time I checked Firefox and IE did things somewhat > differently. May not matter any time soon since to get to a true > browser-like model we'd have to have all JS running on a thread > instead of in the main thread. > > This might mean that WebClient.waitForJobsWithinDelayToFinish will > have to go away for a while since the old version didn't have this > feature. On the plus side, we'll get a job manager that's really unit > testable, which should make adding it back in much easier. > > Thoughts? > > > Brad C > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > -- Daniel Gredler http://daniel.gredler.net/ |
|
From: Brad C. <br...@br...> - 2009-03-02 21:24:31
|
On Mon, Mar 2, 2009 at 1:25 PM, Daniel Gredler <djg...@gm...> wrote: > Hi Brad, > >> The new JS job manager is causing us some major problems. > > Can you write some unit tests for them, so that we can see what you're > seeing? As soon as I can figure out enough of what's going on to get a test written it will be checked in. The ugly part is that I don't yet have a single test that will always fail. My most common case is with a setInterval with a low interval is starting an XmlHttpRequest.send while a setTimeout with a long duration is waiting to kill it all if things take too long. The send and the setInterval communicate through variables so I'm not entirely sure if the problem is our threads or that things have just gotten so efficient that we've exposed a rhino threading problem. Anyway, yes, tests are coming :) > >> Right now I'm thinking about making the job manager pluggable so both >> versions can exist. > > Should be easy, just implement the JavaScriptJobManager interface to your > liking (and use your impl rather than the default impl). I think I might end up with a job manager factory and a job factory, but I don't know at this point. I keep trying new things with the implementation that require interface changes :) > >> I'm about to have to take it out and try it with the old job management > > If you're talking about committing this change, I couldn't disagree more. If > you're talking about a local change, that's fine. But it seems like a > drastic measure given that all of our unit tests are passing. See my comment > to item 1 above. Sorry, I wasn't clear about that. Right now I'm just talking about locally. I'm certain that there's a bug I just can't find it yet. If I can't find it soon then I'd like to at least have it be easy to change between the methods before a release happens so anyone else who has my problem will also have a workaround until we can find out more. Brad C > > Take care, > > Daniel > > > > On Mon, Mar 2, 2009 at 12:00 PM, Brad Clarke <br...@br...> wrote: >> >> The new JS job manager is causing us some major problems. I've tried >> to isolate the problem and could not. I've tried to make it better >> while still using the executor but could not fix everything I was >> seeing. I'm about to have to take it out and try it with the old job >> management but with the rest of post-2.4 changes in place so I'm just >> getting the refactorings and simple changes I've made checked in >> without any of the job management changes. I didn't write tests for >> the window closing stuff because it was just something I happened to >> do while trying to fix the job management. It might be testable but >> it's more about cleaning up properly than any functional changes so I >> didn't spend any time writing tests. >> >> Right now I'm thinking about making the job manager pluggable so both >> versions can exist. I think this will be needed long-term anyway since >> the last time I checked Firefox and IE did things somewhat >> differently. May not matter any time soon since to get to a true >> browser-like model we'd have to have all JS running on a thread >> instead of in the main thread. >> >> This might mean that WebClient.waitForJobsWithinDelayToFinish will >> have to go away for a while since the old version didn't have this >> feature. On the plus side, we'll get a job manager that's really unit >> testable, which should make adding it back in much easier. >> >> Thoughts? >> >> >> Brad C >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> HtmlUnit-develop mailing list >> Htm...@li... >> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > > > > -- > Daniel Gredler > http://daniel.gredler.net/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > > |
|
From: Marc G. <mgu...@ya...> - 2009-03-02 19:21:41
|
Brad Clarke wrote: > The new JS job manager is causing us some major problems. I've tried > to isolate the problem and could not. I've tried to make it better > while still using the executor but could not fix everything I was > seeing. I'm about to have to take it out and try it with the old job > management but with the rest of post-2.4 changes in place so I'm just > getting the refactorings and simple changes I've made checked in > without any of the job management changes. I didn't write tests for > the window closing stuff because it was just something I happened to > do while trying to fix the job management. It might be testable but > it's more about cleaning up properly than any functional changes so I > didn't spend any time writing tests. this is an area where it is sometime extremely difficult to isolate the root cause. What about adding an adequate comment about the missing unit test when you hit such a case? > Right now I'm thinking about making the job manager pluggable so both > versions can exist. I think this will be needed long-term anyway since > the last time I checked Firefox and IE did things somewhat > differently. can you provide some details? I'm not really motivated to have a plugin mechanism there. > May not matter any time soon since to get to a true > browser-like model we'd have to have all JS running on a thread > instead of in the main thread. I think about it since a long time and in fact I imagine that it can be quite easy with the Executors and would allow to simplify our code. > This might mean that WebClient.waitForJobsWithinDelayToFinish will > have to go away for a while since the old version didn't have this > feature. On the plus side, we'll get a job manager that's really unit > testable, which should make adding it back in much easier. No. WebClient.waitForJobsWithinDelayToFinish already provides a better control and I hope to be able to fix the corner cases that still exist before next release. Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com |
|
From: Brad C. <br...@br...> - 2009-03-02 23:00:33
|
On Mon, Mar 2, 2009 at 1:21 PM, Marc Guillemot <mgu...@ya...> wrote: > Brad Clarke wrote: > this is an area where it is sometime extremely difficult to isolate the > root cause. What about adding an adequate comment about the missing unit > test when you hit such a case? > In the future I'll at least try to make the check in message more explicit. If I can find an appropriate place in the code or javadocs for comments I'll add those too. >> Right now I'm thinking about making the job manager pluggable so both >> versions can exist. I think this will be needed long-term anyway since >> the last time I checked Firefox and IE did things somewhat >> differently. > > can you provide some details? I'm not really motivated to have a plugin > mechanism there. > The main thing I remember is that one browser would let a setInterval stack up executions like the Executor does but the other one wouldn't start counting for the next interval until the previous one had finished executing. So if you had a setInterval at 1 second and the JS took 1 second to execute one browser would have the second invovation at 2 seconds from the initial setInterval call while the other would be at 3 seconds. I think this was with FF2 and IE6, so the newer browsers may be different. >> This might mean that WebClient.waitForJobsWithinDelayToFinish will >> have to go away for a while since the old version didn't have this >> feature. On the plus side, we'll get a job manager that's really unit >> testable, which should make adding it back in much easier. > > No. WebClient.waitForJobsWithinDelayToFinish already provides a better > control and I hope to be able to fix the corner cases that still exist > before next release. > In general, I will never side with new functionality over the reliability of old functionality. In this case I'd much prefer to fix the new stuff (it's much nicer to look at), but if we can't then I don't think it'll be a big deal to add the new functionality to the older method. It's just a matter of exposing the delay on the job and then writing something to query the values without crapping its pants :) If there's no objection, tomorrow I will get my finalize my reduced API and check that in with refactorings that use the Executor but don't break any HtmlUnit tests. I won't check in anything to make it pluggable until I can come up with at least one test that shows it is needed. Brad C |
|
From: Daniel G. <djg...@gm...> - 2009-03-02 23:10:15
|
Hi Brad, Just a suggestion: can you post a patch first instead, so that we can all take a look and discuss it? This is starting to feel like "too many cooks in the kitchen", where everyone has an opinion on the best way to implement this, and we end up with a frankensteinian conglomeration of bits and pieces of everyone's vision :-) Thanks, Daniel On Mon, Mar 2, 2009 at 6:00 PM, Brad Clarke <br...@br...> wrote: > On Mon, Mar 2, 2009 at 1:21 PM, Marc Guillemot <mgu...@ya...> > wrote: > > Brad Clarke wrote: > > this is an area where it is sometime extremely difficult to isolate the > > root cause. What about adding an adequate comment about the missing unit > > test when you hit such a case? > > > > In the future I'll at least try to make the check in message more > explicit. If I can find an appropriate place in the code or javadocs > for comments I'll add those too. > > > >> Right now I'm thinking about making the job manager pluggable so both > >> versions can exist. I think this will be needed long-term anyway since > >> the last time I checked Firefox and IE did things somewhat > >> differently. > > > > can you provide some details? I'm not really motivated to have a plugin > > mechanism there. > > > > The main thing I remember is that one browser would let a setInterval > stack up executions like the Executor does but the other one wouldn't > start counting for the next interval until the previous one had > finished executing. So if you had a setInterval at 1 second and the JS > took 1 second to execute one browser would have the second invovation > at 2 seconds from the initial setInterval call while the other would > be at 3 seconds. I think this was with FF2 and IE6, so the newer > browsers may be different. > > > >> This might mean that WebClient.waitForJobsWithinDelayToFinish will > >> have to go away for a while since the old version didn't have this > >> feature. On the plus side, we'll get a job manager that's really unit > >> testable, which should make adding it back in much easier. > > > > No. WebClient.waitForJobsWithinDelayToFinish already provides a better > > control and I hope to be able to fix the corner cases that still exist > > before next release. > > > > In general, I will never side with new functionality over the > reliability of old functionality. In this case I'd much prefer to fix > the new stuff (it's much nicer to look at), but if we can't then I > don't think it'll be a big deal to add the new functionality to the > older method. It's just a matter of exposing the delay on the job and > then writing something to query the values without crapping its pants > :) > > > If there's no objection, tomorrow I will get my finalize my reduced > API and check that in with refactorings that use the Executor but > don't break any HtmlUnit tests. I won't check in anything to make it > pluggable until I can come up with at least one test that shows it is > needed. > > > Brad C > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > -- Daniel Gredler http://daniel.gredler.net/ |
|
From: Brad C. <br...@br...> - 2009-03-02 23:49:19
Attachments:
patch.txt
|
Sure, this is where I'm at right now. Clearly needs a lot of cleanup, but it should give you a good idea of what I'm doing. On Mon, Mar 2, 2009 at 5:10 PM, Daniel Gredler <djg...@gm...> wrote: > Hi Brad, > > Just a suggestion: can you post a patch first instead, so that we can all > take a look and discuss it? > > This is starting to feel like "too many cooks in the kitchen", where > everyone has an opinion on the best way to implement this, and we end up > with a frankensteinian conglomeration of bits and pieces of everyone's > vision :-) > > Thanks, > > Daniel > > > > On Mon, Mar 2, 2009 at 6:00 PM, Brad Clarke <br...@br...> wrote: >> >> On Mon, Mar 2, 2009 at 1:21 PM, Marc Guillemot <mgu...@ya...> >> wrote: >> > Brad Clarke wrote: >> > this is an area where it is sometime extremely difficult to isolate the >> > root cause. What about adding an adequate comment about the missing unit >> > test when you hit such a case? >> > >> >> In the future I'll at least try to make the check in message more >> explicit. If I can find an appropriate place in the code or javadocs >> for comments I'll add those too. >> >> >> >> Right now I'm thinking about making the job manager pluggable so both >> >> versions can exist. I think this will be needed long-term anyway since >> >> the last time I checked Firefox and IE did things somewhat >> >> differently. >> > >> > can you provide some details? I'm not really motivated to have a plugin >> > mechanism there. >> > >> >> The main thing I remember is that one browser would let a setInterval >> stack up executions like the Executor does but the other one wouldn't >> start counting for the next interval until the previous one had >> finished executing. So if you had a setInterval at 1 second and the JS >> took 1 second to execute one browser would have the second invovation >> at 2 seconds from the initial setInterval call while the other would >> be at 3 seconds. I think this was with FF2 and IE6, so the newer >> browsers may be different. >> >> >> >> This might mean that WebClient.waitForJobsWithinDelayToFinish will >> >> have to go away for a while since the old version didn't have this >> >> feature. On the plus side, we'll get a job manager that's really unit >> >> testable, which should make adding it back in much easier. >> > >> > No. WebClient.waitForJobsWithinDelayToFinish already provides a better >> > control and I hope to be able to fix the corner cases that still exist >> > before next release. >> > >> >> In general, I will never side with new functionality over the >> reliability of old functionality. In this case I'd much prefer to fix >> the new stuff (it's much nicer to look at), but if we can't then I >> don't think it'll be a big deal to add the new functionality to the >> older method. It's just a matter of exposing the delay on the job and >> then writing something to query the values without crapping its pants >> :) >> >> >> If there's no objection, tomorrow I will get my finalize my reduced >> API and check that in with refactorings that use the Executor but >> don't break any HtmlUnit tests. I won't check in anything to make it >> pluggable until I can come up with at least one test that shows it is >> needed. >> >> >> Brad C >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> HtmlUnit-develop mailing list >> Htm...@li... >> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > > > > -- > Daniel Gredler > http://daniel.gredler.net/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > > |
|
From: Brad C. <br...@br...> - 2009-03-03 16:37:20
Attachments:
patch2.txt
|
A cleaned up version. The debug logging is probably overboard since I just uncommented everything I had commented before because it was too much :) This one leaves JavaScriptJobManagerImpl with no HtmlUnit related references so it can be unit tested separately. If there's no objection I'd like to write a few tests and check this in. Brad C On Mon, Mar 2, 2009 at 5:49 PM, Brad Clarke <br...@br...> wrote: > Sure, this is where I'm at right now. Clearly needs a lot of cleanup, > but it should give you a good idea of what I'm doing. > > > > On Mon, Mar 2, 2009 at 5:10 PM, Daniel Gredler <djg...@gm...> wrote: >> Hi Brad, >> >> Just a suggestion: can you post a patch first instead, so that we can all >> take a look and discuss it? >> >> This is starting to feel like "too many cooks in the kitchen", where >> everyone has an opinion on the best way to implement this, and we end up >> with a frankensteinian conglomeration of bits and pieces of everyone's >> vision :-) >> >> Thanks, >> >> Daniel >> >> >> >> On Mon, Mar 2, 2009 at 6:00 PM, Brad Clarke <br...@br...> wrote: >>> >>> On Mon, Mar 2, 2009 at 1:21 PM, Marc Guillemot <mgu...@ya...> >>> wrote: >>> > Brad Clarke wrote: >>> > this is an area where it is sometime extremely difficult to isolate the >>> > root cause. What about adding an adequate comment about the missing unit >>> > test when you hit such a case? >>> > >>> >>> In the future I'll at least try to make the check in message more >>> explicit. If I can find an appropriate place in the code or javadocs >>> for comments I'll add those too. >>> >>> >>> >> Right now I'm thinking about making the job manager pluggable so both >>> >> versions can exist. I think this will be needed long-term anyway since >>> >> the last time I checked Firefox and IE did things somewhat >>> >> differently. >>> > >>> > can you provide some details? I'm not really motivated to have a plugin >>> > mechanism there. >>> > >>> >>> The main thing I remember is that one browser would let a setInterval >>> stack up executions like the Executor does but the other one wouldn't >>> start counting for the next interval until the previous one had >>> finished executing. So if you had a setInterval at 1 second and the JS >>> took 1 second to execute one browser would have the second invovation >>> at 2 seconds from the initial setInterval call while the other would >>> be at 3 seconds. I think this was with FF2 and IE6, so the newer >>> browsers may be different. >>> >>> >>> >> This might mean that WebClient.waitForJobsWithinDelayToFinish will >>> >> have to go away for a while since the old version didn't have this >>> >> feature. On the plus side, we'll get a job manager that's really unit >>> >> testable, which should make adding it back in much easier. >>> > >>> > No. WebClient.waitForJobsWithinDelayToFinish already provides a better >>> > control and I hope to be able to fix the corner cases that still exist >>> > before next release. >>> > >>> >>> In general, I will never side with new functionality over the >>> reliability of old functionality. In this case I'd much prefer to fix >>> the new stuff (it's much nicer to look at), but if we can't then I >>> don't think it'll be a big deal to add the new functionality to the >>> older method. It's just a matter of exposing the delay on the job and >>> then writing something to query the values without crapping its pants >>> :) >>> >>> >>> If there's no objection, tomorrow I will get my finalize my reduced >>> API and check that in with refactorings that use the Executor but >>> don't break any HtmlUnit tests. I won't check in anything to make it >>> pluggable until I can come up with at least one test that shows it is >>> needed. >>> >>> >>> Brad C >>> >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>> CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source code: >>> SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> HtmlUnit-develop mailing list >>> Htm...@li... >>> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop >> >> >> >> -- >> Daniel Gredler >> http://daniel.gredler.net/ >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> HtmlUnit-develop mailing list >> Htm...@li... >> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop >> >> > |
|
From: Marc G. <mgu...@ya...> - 2009-03-03 16:52:27
|
Hi Brad, Sorry for overlooking your first mail. After a quick look at your patch: - I like the extension of ScheduledThreadPoolExecutor, this makes code easier (btw why do you add an EventHandler if you want to simplify the API?) - I don't like the change to WebClient.waitForJobsWithinDelayToFinish: it should not have to iterate on all windows and should be able to direct pick the right job to wait for. Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com Brad Clarke wrote: > A cleaned up version. The debug logging is probably overboard since I > just uncommented everything I had commented before because it was too > much :) > > This one leaves JavaScriptJobManagerImpl with no HtmlUnit related > references so it can be unit tested separately. If there's no > objection I'd like to write a few tests and check this in. > > > Brad C > > On Mon, Mar 2, 2009 at 5:49 PM, Brad Clarke <br...@br...> wrote: >> Sure, this is where I'm at right now. Clearly needs a lot of cleanup, >> but it should give you a good idea of what I'm doing. >> >> >> >> On Mon, Mar 2, 2009 at 5:10 PM, Daniel Gredler <djg...@gm...> wrote: >>> Hi Brad, >>> >>> Just a suggestion: can you post a patch first instead, so that we can all >>> take a look and discuss it? >>> >>> This is starting to feel like "too many cooks in the kitchen", where >>> everyone has an opinion on the best way to implement this, and we end up >>> with a frankensteinian conglomeration of bits and pieces of everyone's >>> vision :-) >>> >>> Thanks, >>> >>> Daniel >>> >>> >>> >>> On Mon, Mar 2, 2009 at 6:00 PM, Brad Clarke <br...@br...> wrote: >>>> On Mon, Mar 2, 2009 at 1:21 PM, Marc Guillemot <mgu...@ya...> >>>> wrote: >>>>> Brad Clarke wrote: >>>>> this is an area where it is sometime extremely difficult to isolate the >>>>> root cause. What about adding an adequate comment about the missing unit >>>>> test when you hit such a case? >>>>> >>>> In the future I'll at least try to make the check in message more >>>> explicit. If I can find an appropriate place in the code or javadocs >>>> for comments I'll add those too. >>>> >>>> >>>>>> Right now I'm thinking about making the job manager pluggable so both >>>>>> versions can exist. I think this will be needed long-term anyway since >>>>>> the last time I checked Firefox and IE did things somewhat >>>>>> differently. >>>>> can you provide some details? I'm not really motivated to have a plugin >>>>> mechanism there. >>>>> >>>> The main thing I remember is that one browser would let a setInterval >>>> stack up executions like the Executor does but the other one wouldn't >>>> start counting for the next interval until the previous one had >>>> finished executing. So if you had a setInterval at 1 second and the JS >>>> took 1 second to execute one browser would have the second invovation >>>> at 2 seconds from the initial setInterval call while the other would >>>> be at 3 seconds. I think this was with FF2 and IE6, so the newer >>>> browsers may be different. >>>> >>>> >>>>>> This might mean that WebClient.waitForJobsWithinDelayToFinish will >>>>>> have to go away for a while since the old version didn't have this >>>>>> feature. On the plus side, we'll get a job manager that's really unit >>>>>> testable, which should make adding it back in much easier. >>>>> No. WebClient.waitForJobsWithinDelayToFinish already provides a better >>>>> control and I hope to be able to fix the corner cases that still exist >>>>> before next release. >>>>> >>>> In general, I will never side with new functionality over the >>>> reliability of old functionality. In this case I'd much prefer to fix >>>> the new stuff (it's much nicer to look at), but if we can't then I >>>> don't think it'll be a big deal to add the new functionality to the >>>> older method. It's just a matter of exposing the delay on the job and >>>> then writing something to query the values without crapping its pants >>>> :) >>>> >>>> >>>> If there's no objection, tomorrow I will get my finalize my reduced >>>> API and check that in with refactorings that use the Executor but >>>> don't break any HtmlUnit tests. I won't check in anything to make it >>>> pluggable until I can come up with at least one test that shows it is >>>> needed. >>>> >>>> >>>> Brad C >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>>> CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>> Enterprise >>>> -Strategies to boost innovation and cut costs with open source >>>> participation >>>> -Receive a $600 discount off the registration fee with the source code: >>>> SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> HtmlUnit-develop mailing list >>>> Htm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop >>> >>> >>> -- >>> Daniel Gredler >>> http://daniel.gredler.net/ >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> HtmlUnit-develop mailing list >>> Htm...@li... >>> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop >>> >>> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> HtmlUnit-develop mailing list >> Htm...@li... >> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop |
|
From: Brad C. <br...@br...> - 2009-03-03 17:55:52
|
On Tue, Mar 3, 2009 at 10:52 AM, Marc Guillemot <mgu...@ya...> wrote: > Hi Brad, > > Sorry for overlooking your first mail. No problem, it's a pretty busy list lately :) > After a quick look at your patch: > - I like the extension of ScheduledThreadPoolExecutor, this makes code > easier (btw why do you add an EventHandler if you want to simplify the API?) The EventHandler is more an implementation detail than API. I just wanted the start and stop events to be synchronized on the job manager without making the Executor aware of the job manager directly. The EventHandler was one way of keeping all knowledge of the job manager inside the job manager. I considered making an explicit monitor object but then I'd have just ended up synchronizing on it in every method of the job manager anyway, so I took the easy way out. It's all hidden behind the interface so it can be changed as needed. > - I don't like the change to WebClient.waitForJobsWithinDelayToFinish: > it should not have to iterate on all windows and should be able to > direct pick the right job to wait for. First of all, I don't think efficiency really matters here. By definition you're wasting time, who cares how it's wasted? :) But it was really just another encapsulation decision. WebClients should be responsible for managing windows, not job managers and jobs. The WebClient has enough to do already, leave the work to the child objects. If you wanted something like WebClient.getElementWithIdOnAnyPage(...) would you move the management of ID maps into the WebClient or just iterate through the known windows and ask their enclosed pages? Also, by pushing all that logic into the job manager you add this functionality to each window instead of having to wait on jobs from all windows if you don't want to. I suppose we could use a job manager factory to create the job managers and let the factory link them all together with another event handler, but I don't see how that buys anything more than a couple of trips through an iterator. Brad C |
|
From: Marc G. <mgu...@ya...> - 2009-03-04 08:10:50
|
Hi Brad, >> After a quick look at your patch: >> - I like the extension of ScheduledThreadPoolExecutor, this makes code >> easier (btw why do you add an EventHandler if you want to simplify the API?) > > The EventHandler is more an implementation detail than API. I just > wanted the start and stop events to be synchronized on the job manager > without making the Executor aware of the job manager directly. The > EventHandler was one way of keeping all knowledge of the job manager > inside the job manager. I considered making an explicit monitor object > but then I'd have just ended up synchronizing on it in every method of > the job manager anyway, so I took the easy way out. > > It's all hidden behind the interface so it can be changed as needed. what about committing only the extension of the ScheduledThreadPoolExecutor in a first time? > >> - I don't like the change to WebClient.waitForJobsWithinDelayToFinish: >> it should not have to iterate on all windows and should be able to >> direct pick the right job to wait for. > > First of all, I don't think efficiency really matters here. By > definition you're wasting time, who cares how it's wasted? :) > > But it was really just another encapsulation decision. WebClients > should be responsible for managing windows, not job managers and jobs. > The WebClient has enough to do already, leave the work to the child > objects. If you wanted something like > WebClient.getElementWithIdOnAnyPage(...) would you move the management > of ID maps into the WebClient or just iterate through the known > windows and ask their enclosed pages? > > Also, by pushing all that logic into the job manager you add this > functionality to each window instead of having to wait on jobs from > all windows if you don't want to. > > I suppose we could use a job manager factory to create the job > managers and let the factory link them all together with another event > handler, but I don't see how that buys anything more than a couple of > trips through an iterator. the point is following: I want to be able in WebTest (and it surely makes sense for other users of HtmlUnit) to wait after any action as long as needed for execution of all *relevant* background jobs but not any milliseconds longer (ok, a few ms are ok too). The idea is that when writing a test, a user should not have to notice that a change that he has seen as nearly immediate in his browser (think of Jacob Nielsen's definition of response time: http://www.useit.com/papers/responsetime.html) was delayed. This means that I need to be able to pick the latest job starting within a given time and wait for its completion. And then, maybe a retry strategy if some jobs have been added with a short delay (this needs to be specified more precisely). When you don't have the overview on all jobs but iterate over windows, you won't know if the job you find in window 2 has been triggered by the job in window 1 on which you waited previously or if it was originally planned. Additionally the current implementation in your patch doesn't take execution time into account (as far as I could understand it): if job1 and job2 should start within delay and waiting for completion of job1 takes longer than the delay, I guess the method won't wait for completion of job2. I'll try to add a unit test for that. A good sign for a correct implementation of this method will be when we're able to use it with a short delay (<2000 ms) for all library tests in HtmlUnit. Currently this is not the case: I test with the GWT tests locally and there are still race conditions with tests that don't pass all the time. I have an idea on the reason but I need to investigate it more in details. I guess that your extension of ScheduledThreadPoolExecutor would help a bit here. Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com |
|
From: Brad C. <br...@br...> - 2009-03-04 14:46:21
|
I don't see how any of that is significantly different than what is already there. The only time it won't happen the same as before is if you get background JS running in multiple windows, and then it will make the effort based on one window at a time and then waste a few ms finishing iterating the windows when everything is done. I'm quite certain that the implementation has problems, but all of your issues with this can be tweaked internally at any time (and I intend to do some experimentation with implementation myself). I want to check this in for the interface changes ASAP so we can be working from the same code, as well as to have a job manager that we can write complex unit tests for while doing that work. Brad C On Wed, Mar 4, 2009 at 2:10 AM, Marc Guillemot <mgu...@ya...> wrote: > Hi Brad, > >>> After a quick look at your patch: >>> - I like the extension of ScheduledThreadPoolExecutor, this makes code >>> easier (btw why do you add an EventHandler if you want to simplify the API?) >> >> The EventHandler is more an implementation detail than API. I just >> wanted the start and stop events to be synchronized on the job manager >> without making the Executor aware of the job manager directly. The >> EventHandler was one way of keeping all knowledge of the job manager >> inside the job manager. I considered making an explicit monitor object >> but then I'd have just ended up synchronizing on it in every method of >> the job manager anyway, so I took the easy way out. >> >> It's all hidden behind the interface so it can be changed as needed. > > what about committing only the extension of the > ScheduledThreadPoolExecutor in a first time? > >> >>> - I don't like the change to WebClient.waitForJobsWithinDelayToFinish: >>> it should not have to iterate on all windows and should be able to >>> direct pick the right job to wait for. >> >> First of all, I don't think efficiency really matters here. By >> definition you're wasting time, who cares how it's wasted? :) >> >> But it was really just another encapsulation decision. WebClients >> should be responsible for managing windows, not job managers and jobs. >> The WebClient has enough to do already, leave the work to the child >> objects. If you wanted something like >> WebClient.getElementWithIdOnAnyPage(...) would you move the management >> of ID maps into the WebClient or just iterate through the known >> windows and ask their enclosed pages? >> >> Also, by pushing all that logic into the job manager you add this >> functionality to each window instead of having to wait on jobs from >> all windows if you don't want to. >> >> I suppose we could use a job manager factory to create the job >> managers and let the factory link them all together with another event >> handler, but I don't see how that buys anything more than a couple of >> trips through an iterator. > > the point is following: I want to be able in WebTest (and it surely > makes sense for other users of HtmlUnit) to wait after any action as > long as needed for execution of all *relevant* background jobs but not > any milliseconds longer (ok, a few ms are ok too). The idea is that when > writing a test, a user should not have to notice that a change that he > has seen as nearly immediate in his browser (think of Jacob Nielsen's > definition of response time: > http://www.useit.com/papers/responsetime.html) was delayed. This means > that I need to be able to pick the latest job starting within a given > time and wait for its completion. And then, maybe a retry strategy if > some jobs have been added with a short delay (this needs to be specified > more precisely). When you don't have the overview on all jobs but > iterate over windows, you won't know if the job you find in window 2 has > been triggered by the job in window 1 on which you waited previously or > if it was originally planned. Additionally the current implementation in > your patch doesn't take execution time into account (as far as I could > understand it): if job1 and job2 should start within delay and waiting > for completion of job1 takes longer than the delay, I guess the method > won't wait for completion of job2. I'll try to add a unit test for that. > > A good sign for a correct implementation of this method will be when > we're able to use it with a short delay (<2000 ms) for all library tests > in HtmlUnit. Currently this is not the case: I test with the GWT tests > locally and there are still race conditions with tests that don't pass > all the time. I have an idea on the reason but I need to investigate it > more in details. I guess that your extension of > ScheduledThreadPoolExecutor would help a bit here. > > Cheers, > Marc. > -- > Web: http://www.efficient-webtesting.com > Blog: http://mguillem.wordpress.com > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > |
|
From: Marc G. <mgu...@ya...> - 2009-03-04 14:59:34
|
Brad Clarke wrote: > I don't see how any of that is significantly different than what is > already there. The only time it won't happen the same as before is if > you get background JS running in multiple windows, and then it will > make the effort based on one window at a time and then waste a few ms > finishing iterating the windows when everything is done. it's not only wasting time: what I've tried to explain is that you don't get the same time of information but It seems that I failed to explain it clearly :-( > I'm quite certain that the implementation has problems, but all of > your issues with this can be tweaked internally at any time (and I > intend to do some experimentation with implementation myself). I want > to check this in for the interface changes ASAP so we can be working > from the same code, as well as to have a job manager that we can write > complex unit tests for while doing that work. you mean the extension of the ScheduledThreadPoolExecutor? Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com |
|
From: Brad C. <br...@br...> - 2009-03-04 15:58:30
|
On Wed, Mar 4, 2009 at 8:59 AM, Marc Guillemot <mgu...@ya...> wrote: > Brad Clarke wrote: >> I don't see how any of that is significantly different than what is >> already there. The only time it won't happen the same as before is if >> you get background JS running in multiple windows, and then it will >> make the effort based on one window at a time and then waste a few ms >> finishing iterating the windows when everything is done. > > it's not only wasting time: what I've tried to explain is that you don't > get the same time of information but It seems that I failed to explain > it clearly :-( I understand that you don't get the same information, but that doesn't matter. You're not asking WebClient for information, you're asking it to wait for a certain amount of time based on the state of JS jobs. I don't see anything that makes the amount of time waited significantly different between the 2 implementations (I doubt that it's even measurably different if any waiting happens at all). http://c2.com/cgi/wiki?OptimizeLater >> I'm quite certain that the implementation has problems, but all of >> your issues with this can be tweaked internally at any time (and I >> intend to do some experimentation with implementation myself). I want >> to check this in for the interface changes ASAP so we can be working >> from the same code, as well as to have a job manager that we can write >> complex unit tests for while doing that work. > > you mean the extension of the ScheduledThreadPoolExecutor? If you're asking about the interface, then the parts I care about right now is the changes to JavaScriptJobManager and JavaScriptJob, as well as the removal of JavaScriptJobsSupervisor. The rest of what was done was mostly to make these things possible (a lot of synchronization was added while troubleshooting, but I left it because it makes querying the job count accurate). |
|
From: Marc G. <mgu...@ya...> - 2009-03-04 16:49:52
|
> > I understand that you don't get the same information, but that doesn't > matter. > ... No. It's not only a question of optimization (which doesn't matter here, I agree). I don't have time to try to explain it better than what I've posted previously :-( > > If you're asking about the interface, then the parts I care about > right now is the changes to JavaScriptJobManager and JavaScriptJob, as > well as the removal of JavaScriptJobsSupervisor. The rest of what was > done was mostly to make these things possible (a lot of > synchronization was added while troubleshooting, but I left it because > it makes querying the job count accurate). I'm reluctant about removing the supervisor as you haven't provided any test case showing the problems with current implementation. Nevertheless I understand that it may be difficult to create such tests and if this fixes the issues you have with your app, I'm ok for your changes *if* for instance all GWT15Test pass using something like waitForJobsWithinDelayToFinish(2000) instead of the current waiting mechanisms (waitForAllJobsToFinish and loops with wait). This is not the case with current implementation (or to be precise this is not always the case). Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com |
|
From: Brad C. <br...@br...> - 2009-03-04 19:12:30
|
On Wed, Mar 4, 2009 at 10:49 AM, Marc Guillemot <mgu...@ya...> wrote: > I'm reluctant about removing the supervisor as you haven't provided any > test case showing the problems with current implementation. Nevertheless > I understand that it may be difficult to create such tests and if this > fixes the issues you have with your app, I'm ok for your changes *if* > for instance all GWT15Test pass using > something like waitForJobsWithinDelayToFinish(2000) instead of the > current waiting mechanisms (waitForAllJobsToFinish and loops with wait). > This is not the case with current implementation (or to be precise this > is not always the case). I don't understand what you mean with that last part, but if this makes you feel any better: With current code: ------------------------------------------------------------------------------- Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test ------------------------------------------------------------------------------- Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.814 sec With my code: ------------------------------------------------------------------------------- Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test ------------------------------------------------------------------------------- Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.689 sec If I change GWT15Test.loadGWTPage to page.getWebClient().waitForJobsWithinDelayToFinish(10000) then I get these numbers: before: Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 58.204 sec after: Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 57.517 sec and with page.getWebClient().waitForJobsWithinDelayToFinish(2000) I get this: before: Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.188 sec after: Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.751 sec I ran the last one 10 more times and it always passed with a running time in the 25s I don't know what sort of jobs GWT or any of the other library tests are making so I'm afraid to touch them without knowing what the appropriate wait times would be, but it seems like neither 10000 nor 2000 is the right value for this one. I've LOVE to see all the library tests running faster (build times are far too long right now) and will explore this further very soon if you have not :) |
|
From: Daniel G. <djg...@gm...> - 2009-03-05 07:00:31
|
Hi Brad, Just a note to say that I haven't had a chance to look at your patch yet, but plan on doing so soon :-) Take care, Daniel On Wed, Mar 4, 2009 at 2:12 PM, Brad Clarke <br...@br...> wrote: > On Wed, Mar 4, 2009 at 10:49 AM, Marc Guillemot <mgu...@ya...> > wrote: > > I'm reluctant about removing the supervisor as you haven't provided any > > test case showing the problems with current implementation. Nevertheless > > I understand that it may be difficult to create such tests and if this > > fixes the issues you have with your app, I'm ok for your changes *if* > > for instance all GWT15Test pass using > > something like waitForJobsWithinDelayToFinish(2000) instead of the > > current waiting mechanisms (waitForAllJobsToFinish and loops with wait). > > This is not the case with current implementation (or to be precise this > > is not always the case). > > I don't understand what you mean with that last part, but if this > makes you feel any better: > > With current code: > > ------------------------------------------------------------------------------- > Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test > > ------------------------------------------------------------------------------- > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.814 sec > > With my code: > > ------------------------------------------------------------------------------- > Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test > > ------------------------------------------------------------------------------- > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.689 sec > > > If I change GWT15Test.loadGWTPage to > page.getWebClient().waitForJobsWithinDelayToFinish(10000) then I get > these numbers: > > before: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 58.204 sec > > after: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 57.517 sec > > > and with page.getWebClient().waitForJobsWithinDelayToFinish(2000) I get > this: > > > before: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.188 sec > > after: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.751 sec > > > I ran the last one 10 more times and it always passed with a running > time in the 25s > > I don't know what sort of jobs GWT or any of the other library tests > are making so I'm afraid to touch them without knowing what the > appropriate wait times would be, but it seems like neither 10000 nor > 2000 is the right value for this one. I've LOVE to see all the library > tests running faster (build times are far too long right now) and will > explore this further very soon if you have not :) > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > HtmlUnit-develop mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop > -- Daniel Gredler http://daniel.gredler.net/ |
|
From: Marc G. <mgu...@ya...> - 2009-03-05 08:02:55
|
Hi Brad, I don't expect that waitForJobsWithinDelayToFinish(2000) will make tests running noticeably faster, this is not where we lost most of the time. It should just make tests more deterministic. Something like waitForJobsWithinDelayToFinish(1000) should be OK for all our tests: as far as I know we only test things that are expected to happen asap, therefore there is no need for a big delay. 500 or less would probably be enough as well. What I wanted to say concerning your patch is following. We have now a situation where you're not able to prove with unit tests that your implementation is better. In your implementation you want to change something that I consider as a feature of current implementation of WebClient.waitForJobsWithinDelayToFinish and therefore I have some reserve concerning your patch. But if you say that - with your implementation - all tests of GWT15Test pass using WebClient.waitForJobsWithinDelayToFinish(2000) instead of the different wait mechanisms used there, then it is for me enough to accept the changes in WebClient.waitForJobsWithinDelayToFinish. This proves that your implementation is better and that we should take it as basis for further improvements. Please commit your changes, this discussion has already taken too much time ;-) Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com Brad Clarke wrote: > On Wed, Mar 4, 2009 at 10:49 AM, Marc Guillemot <mgu...@ya...> wrote: >> I'm reluctant about removing the supervisor as you haven't provided any >> test case showing the problems with current implementation. Nevertheless >> I understand that it may be difficult to create such tests and if this >> fixes the issues you have with your app, I'm ok for your changes *if* >> for instance all GWT15Test pass using >> something like waitForJobsWithinDelayToFinish(2000) instead of the >> current waiting mechanisms (waitForAllJobsToFinish and loops with wait). >> This is not the case with current implementation (or to be precise this >> is not always the case). > > I don't understand what you mean with that last part, but if this > makes you feel any better: > > With current code: > ------------------------------------------------------------------------------- > Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test > ------------------------------------------------------------------------------- > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.814 sec > > With my code: > ------------------------------------------------------------------------------- > Test set: com.gargoylesoftware.htmlunit.libraries.GWT15Test > ------------------------------------------------------------------------------- > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.689 sec > > > If I change GWT15Test.loadGWTPage to > page.getWebClient().waitForJobsWithinDelayToFinish(10000) then I get > these numbers: > > before: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 58.204 sec > > after: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 57.517 sec > > > and with page.getWebClient().waitForJobsWithinDelayToFinish(2000) I get this: > > > before: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.188 sec > > after: > Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.751 sec > > > I ran the last one 10 more times and it always passed with a running > time in the 25s > > I don't know what sort of jobs GWT or any of the other library tests > are making so I'm afraid to touch them without knowing what the > appropriate wait times would be, but it seems like neither 10000 nor > 2000 is the right value for this one. I've LOVE to see all the library > tests running faster (build times are far too long right now) and will > explore this further very soon if you have not :) |
Thanks for helping keep SourceForge clean.
X