Loading ...
Sorry, an error occurred while loading the content.

FitClient early termination

Expand Messages
  • rr42volpe
    I just tried switching to the maven version 20100103 of fitnesse. When running from JUnitHelper - immediately after startup of fitnesse I see the following
    Message 1 of 11 , Feb 1, 2010
    • 0 Attachment
      I just tried switching to the maven version 20100103 of fitnesse.

      When running from JUnitHelper - immediately after startup of fitnesse I see the following exception:

      Exception in thread "FitClient early termination" java.lang.NullPointerException
      at fitnesse.components.CommandRunningFitClient$EarlyTerminationRunnable.run(CommandRunningFitClient.java:179)
      at java.lang.Thread.run(Thread.java:619)

      The exception seems to be benign - because everything else continues to work as expected. However - I was wondering if anyone has seen this and knows what might be happening here.

      Thanks.

      Robert
    • rr42volpe
      Here s some more details about this issue. Because I am running using JUnitHelper - the debug command is setting fastTest to true. This in turn uses
      Message 2 of 11 , Feb 1, 2010
      • 0 Attachment
        Here's some more details about this issue. Because I am running using JUnitHelper - the "debug" command is setting fastTest to true. This in turn uses MockCommandRunner as the commandRunner in CommandRunningFitClient.

        MockCommandRunner overrides all of the methods that would initialize the contained "process" variable.

        Therefore, the following code (see below) which contains "commandRunner.process.waitFor()" throws a NullPointerException.

        I'm not sure exactly what the purpose of this code is - so I don't know if simply wrapping the call in an if block that checks (commandRunner.process != null) is solving the problem, or covering it up.

        I also don't know if I have special circumstances that make me see this problem and no one else? I tried making my test pretty basic. I am using a FitLibrary DoFixture - if that has an effect on how all of this gets processed. I was using FitLibrary 20081102, and switched to FitLibrary 20091020, but both give the same issue.

        Thanks for your thoughts.

        Robert

        private class EarlyTerminationRunnable implements Runnable {
        public void run() {
        try {
        Thread.sleep(1000); // next waitFor() can finish too quickly on Linux!
        commandRunner.process.waitFor();
        synchronized (CommandRunningFitClient.this) {
        if (!connectionEstablished) {
        CommandRunningFitClient.this.notify();
        listener.exceptionOccurred(new Exception(
        "FitClient: external process terminated before a connection could be established."));
        }
        }
        }
        catch (InterruptedException e) {
        // ok
        }
        }
        }

        --- In fitnesse@yahoogroups.com, "rr42volpe" <robert.jboss@...> wrote:
        >
        > I just tried switching to the maven version 20100103 of fitnesse.
        >
        > When running from JUnitHelper - immediately after startup of fitnesse I see the following exception:
        >
        > Exception in thread "FitClient early termination" java.lang.NullPointerException
        > at fitnesse.components.CommandRunningFitClient$EarlyTerminationRunnable.run(CommandRunningFitClient.java:179)
        > at java.lang.Thread.run(Thread.java:619)
        >
        > The exception seems to be benign - because everything else continues to work as expected. However - I was wondering if anyone has seen this and knows what might be happening here.
        >
        > Thanks.
        >
        > Robert
        >
      • rr42volpe
        Ok. I m not sure - but I am guessing that I am running into FitNesse and FitLibrary compatibility problems. I d love to use the newest FitNesse 20100103 (if
        Message 3 of 11 , Feb 1, 2010
        • 0 Attachment
          Ok. I'm not sure - but I am guessing that I am running into FitNesse and FitLibrary compatibility problems. I'd love to use the newest FitNesse 20100103 (if possible) - because I've got some deeply nested tests that run extremely slowly without the recent fixes.

          At the same time - I think FitLibrary may have some issues with the latest FitNesse. I would like to use DoFixture's setStopOnError(true) - but that is leading to exceptions running with JUnitHelper. I'm guessing - but am not sure - that this is due to a version problem. Is there a version of FitNesse that FitLibrary 20091020 is known to work with?

          Does anyone have any recommendations on the best combo of these two, and/or the roadmap for supporting FitLibrary with the latest version of FitNesse?

          Thanks.

          Robert

          --- In fitnesse@yahoogroups.com, "rr42volpe" <robert.jboss@...> wrote:
          >
          > I just tried switching to the maven version 20100103 of fitnesse.
          >
          > When running from JUnitHelper - immediately after startup of fitnesse I see the following exception:
          >
          > Exception in thread "FitClient early termination" java.lang.NullPointerException
          > at fitnesse.components.CommandRunningFitClient$EarlyTerminationRunnable.run(CommandRunningFitClient.java:179)
          > at java.lang.Thread.run(Thread.java:619)
          >
          > The exception seems to be benign - because everything else continues to work as expected. However - I was wondering if anyone has seen this and knows what might be happening here.
          >
          > Thanks.
          >
          > Robert
          >
        • chun ji
          Hi all, There are 2 test cases, tc1 and tc2, both are written in fitnesse.   We want to run tc1 100+ times reperatedly to create enough data in the DB, so
          Message 4 of 11 , Feb 2, 2010
          • 0 Attachment
            Hi all,
            There are 2 test cases, tc1 and tc2, both are written in fitnesse.
             
            We want to run tc1 100+ times reperatedly to create enough data in the DB, so that when tc2 is executed, we could check the performance.
             
            So the question is how can I make tc1 running that many times with just one click ?
             
             
            cji

             

          • Gregor Gramlich
            Hi Cji, short answer: you cannot. longer answer: you should not go this road. Gojko Adzic wrote a blog post, that might help you.
            Message 5 of 11 , Feb 2, 2010
            • 0 Attachment
              Hi Cji,

              short answer: you cannot.

              longer answer: you should not go this road. Gojko Adzic wrote a blog post, that might help you.
              Gregor


              2010/2/2 chun ji <cji_work@...>
               

              Hi all,
              There are 2 test cases, tc1 and tc2, both are written in fitnesse.
               
              We want to run tc1 100+ times reperatedly to create enough data in the DB, so that when tc2 is executed, we could check the performance.
               
              So the question is how can I make tc1 running that many times with just one click ?
               
               
              cji

               


            • jroets01
              Gojko s article is right on. Just to be a bit more explicit... Instead of trying to do something like this... ... it is much much better to specify this as...
              Message 6 of 11 , Feb 3, 2010
              • 0 Attachment
                Gojko's article is right on. Just to be a bit more explicit...

                Instead of trying to do something like this...

                |While|i=0|i<5|i++|
                |put book in the cart|i|
                |confirm selection|i|

                it is much much better to specify this as...

                |buy|5|books|

                So, my suggestion is that you do the better approach and extend your fixture to accept an input to tell it how many times it should do what you want it to do.

                Now, if this is a commonly reused set-up where you vary the number of items you want to put into the db, adhere to DRY principles. One way to do this is described at the bottom of http://fitnesse.org/FitNesse.UserGuide.MarkupPageInclude. Using the book example...

                |buy|${NUM_BOOKS_TO_BUY}|books|

                And then if you have a case where there are to be 5 books, you could do this:

                !define NUM_BOOKS_TO_BUY 5
                !include PathToBookBuyingTest

                And if you have a case where you need 100 books, you do this:

                !define NUM_BOOKS_TO_BUY 100
                !include PathToBookBuyingTest

                You do what you want with one click, ensuring that tc1 will run just before tc2, by placing/including tc1 above tc2 on the same page.

                John

                --- In fitnesse@yahoogroups.com, Gregor Gramlich <gramlich@...> wrote:
                >
                > Hi Cji,
                >
                > short answer: you cannot.
                >
                > longer answer: you should not go this road. Gojko Adzic wrote a blog post,
                > that might help you.
                > http://gojko.net/2009/03/09/how-to-implement-loops-in-fitnesse-test-fixtures/
                >
                > Gregor
                >
                >
                > 2010/2/2 chun ji <cji_work@...>
                >
                > >
                > >
                > > Hi all,
                > > There are 2 test cases, tc1 and tc2, both are written in fitnesse.
                > >
                > > We want to run tc1 100+ times reperatedly to create enough data in the DB,
                > > so that when tc2 is executed, we could check the performance.
                > >
                > > So the question is how can I make tc1 running that many times with just one
                > > click ?
                > >
                > >
                > > cji
              • rr42volpe
                I now see what the issue is - and when it is appearing. Can someone add the following fix? As I mentioned earlier, the problem is that MockCommandRunner does
                Message 7 of 11 , Feb 4, 2010
                • 0 Attachment
                  I now see what the issue is - and when it is appearing. Can someone add the following fix?

                  As I mentioned earlier, the problem is that MockCommandRunner does not create a process object, but CommandRunningFitClient is making a call to commandRunner.process.waitFor() (Line:197 in EarlyTerminationRunnable) - which throws a NullPointerException because process is null

                  In order to see this, you need to run using JUnitHelper which sets fastTest to true. Additionally, there is a wait of 1 second before this call. Therefore, you will not see this unless your test takes longer than 1 second to run. Add "Thread.sleep(5000);" into any of your test fixture calls of the test being run from JUnitHelper, and you should get this NullPointerException.

                  I think the solution is that we don't care about EarlyTerminationRunnable when fastTest is true. We may not care about TimeoutThread either - but I'm not exactly sure.

                  So - the solution affects lines (85-88 of CommandRunnningFitClient. Just wrap the threads we don't want to create in an if.

                  if (!fastClient) {
                  timeoutThread = new Thread(new TimeoutRunnable(), "FitClient timeout");
                  timeoutThread.start();
                  earlyTerminationThread = new Thread(new EarlyTerminationRunnable(), "FitClient early termination");
                  earlyTerminationThread.start();
                  }


                  No one has replied to this thread. Can someone confirm whether or not you are willing to add this fix?

                  Thanks.

                  Robert

                  --- In fitnesse@yahoogroups.com, "rr42volpe" <robert.jboss@...> wrote:
                  >
                  > Ok. I'm not sure - but I am guessing that I am running into FitNesse and FitLibrary compatibility problems. I'd love to use the newest FitNesse 20100103 (if possible) - because I've got some deeply nested tests that run extremely slowly without the recent fixes.
                  >
                  > At the same time - I think FitLibrary may have some issues with the latest FitNesse. I would like to use DoFixture's setStopOnError(true) - but that is leading to exceptions running with JUnitHelper. I'm guessing - but am not sure - that this is due to a version problem. Is there a version of FitNesse that FitLibrary 20091020 is known to work with?
                  >
                  > Does anyone have any recommendations on the best combo of these two, and/or the roadmap for supporting FitLibrary with the latest version of FitNesse?
                  >
                  > Thanks.
                  >
                  > Robert
                  >
                  > --- In fitnesse@yahoogroups.com, "rr42volpe" <robert.jboss@> wrote:
                  > >
                  > > I just tried switching to the maven version 20100103 of fitnesse.
                  > >
                  > > When running from JUnitHelper - immediately after startup of fitnesse I see the following exception:
                  > >
                  > > Exception in thread "FitClient early termination" java.lang.NullPointerException
                  > > at fitnesse.components.CommandRunningFitClient$EarlyTerminationRunnable.run(CommandRunningFitClient.java:179)
                  > > at java.lang.Thread.run(Thread.java:619)
                  > >
                  > > The exception seems to be benign - because everything else continues to work as expected. However - I was wondering if anyone has seen this and knows what might be happening here.
                  > >
                  > > Thanks.
                  > >
                  > > Robert
                  > >
                  >
                • Robert Martin
                  ... Robert, Thanks for the fix. I pushed it to github. About an hour from now you ought to be able to download the latest EDGE version that has the fix. ...
                  Message 8 of 11 , Feb 5, 2010
                  • 0 Attachment
                    > Re: FitClient early termination
                    > Posted by: "rr42volpe" robert.jboss@... rr42volpe
                    > Thu Feb 4, 2010 9:30 am (PST)
                    >
                    >
                    >
                    > I now see what the issue is - and when it is appearing. Can someone add the following fix?
                    >
                    > As I mentioned earlier, the problem is that MockCommandRunner does not create a process object, but CommandRunningFitClient is making a call to commandRunner.process.waitFor() (Line:197 in EarlyTerminationRunnable) - which throws a NullPointerException because process is null
                    >
                    > In order to see this, you need to run using JUnitHelper which sets fastTest to true. Additionally, there is a wait of 1 second before this call. Therefore, you will not see this unless your test takes longer than 1 second to run. Add "Thread.sleep(5000);" into any of your test fixture calls of the test being run from JUnitHelper, and you should get this NullPointerException.
                    >
                    > I think the solution is that we don't care about EarlyTerminationRunnable when fastTest is true. We may not care about TimeoutThread either - but I'm not exactly sure.
                    >
                    > So - the solution affects lines (85-88 of CommandRunnningFitClient. Just wrap the threads we don't want to create in an if.
                    >
                    > if (!fastClient) {
                    > timeoutThread = new Thread(new TimeoutRunnable(), "FitClient timeout");
                    > timeoutThread.start();
                    > earlyTerminationThread = new Thread(new EarlyTerminationRunnable(), "FitClient early termination");
                    > earlyTerminationThread.start();
                    > }
                    >
                    > No one has replied to this thread. Can someone confirm whether or not you are willing to add this fix?
                    >
                    > Thanks.

                    Robert,

                    Thanks for the fix. I pushed it to github. About an hour from now you ought to be able to download the latest EDGE version that has the fix.


                    ----
                    Robert C. Martin (Uncle Bob) | email: unclebob@...
                    Object Mentor Inc. | blog: blog.objectmentor.com
                    The Agile Transition Experts | web: www.objectmentor.com
                    800-338-6716 | twitter: unclebobmartin
                  • Lubos Ilcik
                    ...   Lubos ... From: jroets01 Subject: [fitnesse] Re: Running one fitness test case multiple times. To: fitnesse@yahoogroups.com Date:
                    Message 9 of 11 , Apr 19, 2010
                    • 0 Attachment
                      We are just solving the similiar issue and have found these hints useful. What if we need to generate the load for some period of time, would be ok to specify it like this:
                      |buy|5|books|100|times|
                       
                      Lubos

                      --- On Wed, 2/3/10, jroets01 <jroets@...> wrote:

                      From: jroets01 <jroets@...>
                      Subject: [fitnesse] Re: Running one fitness test case multiple times.
                      To: fitnesse@yahoogroups.com
                      Date: Wednesday, February 3, 2010, 2:45 PM

                       
                      Gojko's article is right on. Just to be a bit more explicit...

                      Instead of trying to do something like this...

                      |While|i=0|i< 5|i++|
                      |put book in the cart|i|
                      |confirm selection|i|

                      it is much much better to specify this as...

                      |buy|5|books|

                      So, my suggestion is that you do the better approach and extend your fixture to accept an input to tell it how many times it should do what you want it to do.

                      Now, if this is a commonly reused set-up where you vary the number of items you want to put into the db, adhere to DRY principles. One way to do this is described at the bottom of http://fitnesse. org/FitNesse. UserGuide. MarkupPageInclud e. Using the book example...

                      |buy|${NUM_BOOKS_ TO_BUY}|books|

                      And then if you have a case where there are to be 5 books, you could do this:

                      !define NUM_BOOKS_TO_ BUY 5
                      !include PathToBookBuyingTes t

                      And if you have a case where you need 100 books, you do this:

                      !define NUM_BOOKS_TO_ BUY 100
                      !include PathToBookBuyingTes t

                      You do what you want with one click, ensuring that tc1 will run just before tc2, by placing/including tc1 above tc2 on the same page.

                      John

                      --- In fitnesse@yahoogroup s.com, Gregor Gramlich <gramlich@.. .> wrote:
                      >
                      > Hi Cji,
                      >
                      > short answer: you cannot.
                      >
                      > longer answer: you should not go this road. Gojko Adzic wrote a blog post,
                      > that might help you.
                      > http://gojko. net/2009/ 03/09/how- to-implement- loops-in- fitnesse- test-fixtures/
                      >
                      > Gregor
                      >
                      >
                      > 2010/2/2 chun ji <cji_work@.. .>
                      >
                      > >
                      > >
                      > > Hi all,
                      > > There are 2 test cases, tc1 and tc2, both are written in fitnesse.
                      > >
                      > > We want to run tc1 100+ times reperatedly to create enough data in the DB,
                      > > so that when tc2 is executed, we could check the performance.
                      > >
                      > > So the question is how can I make tc1 running that many times with just one
                      > > click ?
                      > >
                      > >
                      > > cji


                    • jenisys815
                      ... That is not quite true. The correct answer is: It depends. 1. If you want to repeat a row in a table, the answer is to use FitDecorator (if you are not
                      Message 10 of 11 , Apr 19, 2010
                      • 0 Attachment
                        --- In fitnesse@yahoogroups.com, Gregor Gramlich <gramlich@...> wrote:
                        > short answer: you cannot.

                        That is not quite true.
                        The correct answer is: It depends.

                        1. If you want to repeat a row in a table,
                        the answer is to use FitDecorator (if you are not using SLIM).
                        It allows to generate a number of additional rows in table.
                        It basically provides mechanisms to copy N rows and modify some column(s) in each row.

                        FitDecororator is provided for Java and Python.
                        The Java implementation is currently distributed with fitnesse.jar.
                        Therefore, you should be able use it out-of-the-box.

                        2. If you want to repeat a test page (in Fitnesse),
                        you provide provide your own batch-driven test runner that does that.
                        I created a similar one for Python (using/extending PyFIT).

                        SEE ALSO:
                        http://fitdecorator.sourceforge.net/

                        Ciao,
                        Jens
                      • webtester1122
                        I am getting the FitClient Early Termination error as well. I am trying to run fitnesse tests using maven-trinidad-plugin. How do I get the fix for this issue?
                        Message 11 of 11 , Jul 7 4:10 PM
                        • 0 Attachment
                          I am getting the FitClient Early Termination error as well.

                          I am trying to run fitnesse tests using maven-trinidad-plugin.

                          How do I get the fix for this issue?



                          --- In fitnesse@yahoogroups.com, Robert Martin <UncleBob@...> wrote:
                          >
                          > > Re: FitClient early termination
                          > > Posted by: "rr42volpe" robert.jboss@... rr42volpe
                          > > Thu Feb 4, 2010 9:30 am (PST)
                          > >
                          > >
                          > >
                          > > I now see what the issue is - and when it is appearing. Can someone add the following fix?
                          > >
                          > > As I mentioned earlier, the problem is that MockCommandRunner does not create a process object, but CommandRunningFitClient is making a call to commandRunner.process.waitFor() (Line:197 in EarlyTerminationRunnable) - which throws a NullPointerException because process is null
                          > >
                          > > In order to see this, you need to run using JUnitHelper which sets fastTest to true. Additionally, there is a wait of 1 second before this call. Therefore, you will not see this unless your test takes longer than 1 second to run. Add "Thread.sleep(5000);" into any of your test fixture calls of the test being run from JUnitHelper, and you should get this NullPointerException.
                          > >
                          > > I think the solution is that we don't care about EarlyTerminationRunnable when fastTest is true. We may not care about TimeoutThread either - but I'm not exactly sure.
                          > >
                          > > So - the solution affects lines (85-88 of CommandRunnningFitClient. Just wrap the threads we don't want to create in an if.
                          > >
                          > > if (!fastClient) {
                          > > timeoutThread = new Thread(new TimeoutRunnable(), "FitClient timeout");
                          > > timeoutThread.start();
                          > > earlyTerminationThread = new Thread(new EarlyTerminationRunnable(), "FitClient early termination");
                          > > earlyTerminationThread.start();
                          > > }
                          > >
                          > > No one has replied to this thread. Can someone confirm whether or not you are willing to add this fix?
                          > >
                          > > Thanks.
                          >
                          > Robert,
                          >
                          > Thanks for the fix. I pushed it to github. About an hour from now you ought to be able to download the latest EDGE version that has the fix.
                          >
                          >
                          > ----
                          > Robert C. Martin (Uncle Bob) | email: unclebob@...
                          > Object Mentor Inc. | blog: blog.objectmentor.com
                          > The Agile Transition Experts | web: www.objectmentor.com
                          > 800-338-6716 | twitter: unclebobmartin
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.