question about running http requests in parallel

[Mohammad Kolahdouzan]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi,

I am very new to the Grinder and Python (only 2 days) and have a question that may be an awfully simple one!

I have a test case that is similar to:
1. sending 3 http requests (foo.com/x=a1, foo.com/x=b1, bar.com/y=c1) in parallel, wait for them to come back
2. send http request foo.com/x=a2, wait for it to come back
3. send http request bar.com/y=c2, wait for it to come back.

Doing steps 2 and 3 I guess is straight forward (similar to simple HTTP example in the gallery, with 2 calls after each other). What I am not sure is how to apply the example for running scripts in parallel to my case. Note that those a1,b1,c1,a2,c2 are parameters that are supposed to be changing for every run, and I want to be able to run hundreds of these test case (in the order mentioned) at any given time.

Any help is very much appreciated.
-M

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Philip Aston-2]

Mohammad Kolahdouzan wrote:

> I am very new to the Grinder and Python (only 2 days) and have a
> question that may be an awfully simple one!
>
> I have a test case that is similar to:
> 1. sending 3 http requests (foo.com/x=a1, foo.com/x=b1, bar.com/y=c1)
> in parallel, wait for them to come back
> 2. send http request foo.com/x=a2, wait for it to come back
> 3. send http request bar.com/y=c2, wait for it to come back.
>
> Doing steps 2 and 3 I guess is straight forward (similar to simple
> HTTP example in the gallery, with 2 calls after each other). What I am
> not sure is how to apply the example for running scripts in parallel
> to my case. Note that those a1,b1,c1,a2,c2 are parameters that are
> supposed to be changing for every run, and I want to be able to run
> hundreds of these test case (in the order mentioned) at any given time.

I'm afraid this scenario is not easily implemented in a grinder script
due to lack of an easy API for synchronisation between worker threads.
(I'll may fix this one day....)

You can use Python or Java synchronisation primitives to achieve this,
but it requires a good knowledge of multi-threaded programming. If you
want to have a go, you might look at the Java CyclicBarrier class -
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CyclicBarrier.html

- Phil

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Tuvell_Walter]

I know Grinder supports network-level timeouts:
HTTPPluginControl.getConnectionDefaults().setTimeout().

But suppose you're using Grinder to test a Web Service that takes a very
long time (minute scale) to service requests (either because the service
itself is very slow/complicated, or because the server under development
is buggy, whatever).  In that case, net-level timeouts aren't
applicable, and what you want are app-level time-outs.

I tried implementing this, but wasn't successful.  What I tried to do
was set a timer in a Worker thread, putting the WS call Grinder request
(testRequest.POST(), say) into a sub-thread.  If the WS call returned
before the timer fired, then the timer was canceled, and usual Grinder
measurements were recorded for the successful call.  If the call took
too long and the timer fired first, then the WS call sub-thread was
canceled, and the call was recorded as a failure (as a user-configurable
statistic).  [I did all this using a try/except construct, but that's
irrelevant I think.]

But that implementation didn't work.  The problem was that the Grinder
framework threw an exception, because it didn't like the Grinder request
being done in a sub-thread (it wanted the call to be done in the regular
Worker thread).

Has anybody tried to do something like app-level timeouts, and been
successful, either working around the restriction mentioned above, or
using some other technique?

Alternatively, would app-level timeouts make a useful enhancement to the
Grinder framework itself?

- Walt

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Philip Aston-3]

Tuvell_Walter@... wrote:

> I know Grinder supports network-level timeouts:
> HTTPPluginControl.getConnectionDefaults().setTimeout().
>
> But suppose you're using Grinder to test a Web Service that takes a very
> long time (minute scale) to service requests (either because the service
> itself is very slow/complicated, or because the server under development
> is buggy, whatever).  In that case, net-level timeouts aren't
> applicable, and what you want are app-level time-outs.
>
> I tried implementing this, but wasn't successful.  What I tried to do
> was set a timer in a Worker thread, putting the WS call Grinder request
> (testRequest.POST(), say) into a sub-thread.  If the WS call returned
> before the timer fired, then the timer was canceled, and usual Grinder
> measurements were recorded for the successful call.  If the call took
> too long and the timer fired first, then the WS call sub-thread was
> canceled, and the call was recorded as a failure (as a user-configurable
> statistic).  [I did all this using a try/except construct, but that's
> irrelevant I think.]
>
> But that implementation didn't work.  The problem was that the Grinder
> framework threw an exception, because it didn't like the Grinder request
> being done in a sub-thread (it wanted the call to be done in the regular
> Worker thread).
>
> Has anybody tried to do something like app-level timeouts, and been
> successful, either working around the restriction mentioned above, or
> using some other technique?
>
> Alternatively, would app-level timeouts make a useful enhancement to the
> Grinder framework itself?
>
> - Walt
>  

As a workaround, you could make sure everything you do in your "sub
thread" avoids the use of grinder API's, including Tests. E.g. spawn
your thread from within a function, and wrap the function in a Test
rather than the invocation. You'd also have to avoid the HTTPClient
support (which uses the worker thread as context for storing cookies
etc.), so that might be unacceptably restrictive.

See what happens if you launch the timer in a sub thread, and call
interrupt on the worker thread if the time expires. The Grinder code is
pretty good about handling interrupts sensibly, but third party code may
not be, so your mileage may vary.

- Phil



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Tuvell_Walter]

Phil, thank you for your suggestions.  I tried implementing one of them
(perhaps not exactly the way you had in mind), and am here reporting my
results.

First, here are some snippets from my Grinder script:


. . .

g_appTimeout = 3  # millisec (small, for dev/debug)

. . .

class AppTimeoutException(java.lang.Exception):
    pass

class AppTimeout(java.util.TimerTask):
    m_threadId = None

    def __init__(self, i_threadId):
        self.m_threadId = i_threadId

    def run(self):
        excep = AppTimeoutException()
        self.m_threadId.stop(excep)

. . .

def sendReceiveTestRequest(
    i_msgType, i_proto, i_uri, i_msgContent
):
    . . .
    try:
        if g_appTimeout > 0:
            appTimeout = AppTimeout(java.lang.Thread.currentThread())
            timer = java.util.Timer()
            timer.schedule(appTimeout, g_appTimeout)

        testResponse = None  # initialize in case of exception
        if   i_msgType == 'POST':    # ~ "CREATE"
            testResponse = i_testRequest.POST(
g_baseUri[i_proto]+i_uri, i_msgContent)
        elif i_msgType == 'GET':     # ~ "READ"
            testResponse = i_testRequest.GET(
g_baseUri[i_proto]+i_uri, i_msgContent)
        elif i_msgType == 'PUT':     # ~ "UPDATE"
            testResponse = i_testRequest.PUT(
g_baseUri[i_proto]+i_uri, i_msgContent)
        elif i_msgType == 'DELETE':  # ~ "DELETE"
            testResponse =
i_testRequest.DELETE(g_baseUri[i_proto]+i_uri)  # no i_msgContent
        else:
            exit(99, '*** INTERNAL ERROR ***')

        if g_appTimeout > 0:
            timer.cancel()

    except java.lang.Exception:
        if g_verboseSendRecv:
            g_sendLock.acquire(); g_numSends-=1; g_sendLock.release();
        if g_verboseAppTimeout:
            endTime = java.lang.System.currentTimeMillis()
            printInfo(i_opName+' APP TIMEOUT FAILURE', i_targetHost,
i_targetUser,
                      i_time=endTime-startTime)
        # Report timeout.
        #grinder.getStatistics().getForLastTest().setLong("userLong1",
1)
        #grinder.getStatistics().getForLastTest().addLong("userLong2",
1)
        # At this point, because of the exception, this test is marked
as failed.
        # So we must reset it to successful, else timeout stats won't
get reported.
        #grinder.getStatistics().getForLastTest().setSuccess(True)
        return 'HANDLEDEXCEPTION'
    . . .
}

. . .


Note that I had to comment-out the grinder.getStatistics() calls,
because otherwise I (sometimes) get:
"net.grinder.script.InvalidContextException: No tests have been
performed by this thread."  Unfortunately, this means I can't get the
reports/stats I want (per the comment in the code above).

The above code "works", in the sense that if the Web Service call
(invocation of i_testRequest.OPERATION()) takes too longer than
g_appTimeout, then the timer fires and stop()'s the worker thread.
Otherwise, the timer is cancelled, and the worker proceeds on as usual.

And when I run the above code, it sometimes actually works as hoped.
But more often (timing-related), I hit some errors.  For a typical run,
the following is what I got printed out on stdout (Grinder messages are
interspersed with my own messages) [and, Grinder logfiles are attached]:


9/9/08 5:55:19 PM (process tuvelw490-0): starting threads

2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
SOAP_READ SEND
      0_00 00:02.529| TARGETNODE=10.5.115.251  TARGETUSER=userZ
POOLLEN=14 [BYTES=65]
         0      1836| OUTSTANDINGSENDS=1
OBJID=5ca1ab1e0a0573fc048c69019228e3048c6993f0dc31

2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
SOAP_READ APP TIMEOUT FAILURE
      0_00 00:02.537| TARGETNODE=10.5.115.251  TARGETUSER=userZ
         8         8| TIME=3
9/9/08 5:55:21 PM (process tuvelw490-0): There were errors, see
/tmp/LogGrinder/error_tuvelw490-0.log for full details
9/9/08 5:55:21 PM (thread 0 run 0): Aborted run due to Java exception
calling TestRunner

2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
REST_READ SEND
      0_00 00:02.547| TARGETNODE=10.5.115.251  TARGETUSER=userX
POOLLEN=14 [BYTES=65]
        10        10| OUTSTANDINGSENDS=1
OBJID=5ca1ab1e0a0573fc048c69019228e3048c6908a348d5

2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
REST_READ APP TIMEOUT FAILURE
      0_00 00:02.553| TARGETNODE=10.5.115.251  TARGETUSER=userX
         6         6| TIME=4
9/9/08 5:55:21 PM (process tuvelw490-0): finished
Exception in thread "Grinder thread 0" java.lang.AssertionError:
net.grinder.engine.process.DispatchContext$DispatchStateException: No
statistics to report
        at
net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
atchContext(ThreadContextImplementation.java:279)
        at
net.grinder.engine.process.ThreadContextImplementation$3.endRun(ThreadCo
ntextImplementation.java:118)
        at
net.grinder.engine.process.ThreadContextImplementation$6.inform(ThreadCo
ntextImplementation.java:176)
        at
net.grinder.util.ListenerSupport.apply(ListenerSupport.java:92)
        at
net.grinder.engine.process.ThreadContextImplementation.fireEndRunEvent(T
hreadContextImplementation.java:174)
        at
net.grinder.engine.process.GrinderThread.run(GrinderThread.java:142)
        at java.lang.Thread.run(Thread.java:675)
Caused by:
net.grinder.engine.process.DispatchContext$DispatchStateException: No
statistics to report
        at
net.grinder.engine.process.TestData$Dispatcher.report(TestData.java:256)
        at
net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
atchContext(ThreadContextImplementation.java:276)
        ... 6 more

9/9/08 5:55:22 PM (agent): finished


I remain open to further suggestions.

- Walt



 

-----Original Message-----
From: grinder-use-bounces@...
[mailto:grinder-use-bounces@...] On Behalf Of Philip
Aston
Sent: Monday, September 01, 2008 2:31 PM
To: grinder-use
Subject: Re: [Grinder-use] Application-level timeouts

Tuvell_Walter@... wrote:
> I know Grinder supports network-level timeouts:
> HTTPPluginControl.getConnectionDefaults().setTimeout().
>
> But suppose you're using Grinder to test a Web Service that takes a
very
> long time (minute scale) to service requests (either because the
service
> itself is very slow/complicated, or because the server under
development
> is buggy, whatever).  In that case, net-level timeouts aren't
> applicable, and what you want are app-level time-outs.
>
> I tried implementing this, but wasn't successful.  What I tried to do
> was set a timer in a Worker thread, putting the WS call Grinder
request
> (testRequest.POST(), say) into a sub-thread.  If the WS call returned
> before the timer fired, then the timer was canceled, and usual Grinder
> measurements were recorded for the successful call.  If the call took
> too long and the timer fired first, then the WS call sub-thread was
> canceled, and the call was recorded as a failure (as a
user-configurable
> statistic).  [I did all this using a try/except construct, but that's
> irrelevant I think.]
>
> But that implementation didn't work.  The problem was that the Grinder
> framework threw an exception, because it didn't like the Grinder
request
> being done in a sub-thread (it wanted the call to be done in the
regular
> Worker thread).
>
> Has anybody tried to do something like app-level timeouts, and been
> successful, either working around the restriction mentioned above, or
> using some other technique?
>
> Alternatively, would app-level timeouts make a useful enhancement to
the
> Grinder framework itself?
>
> - Walt
>  

As a workaround, you could make sure everything you do in your "sub
thread" avoids the use of grinder API's, including Tests. E.g. spawn
your thread from within a function, and wrap the function in a Test
rather than the invocation. You'd also have to avoid the HTTPClient
support (which uses the worker thread as context for storing cookies
etc.), so that might be unacceptably restrictive.

See what happens if you launch the timer in a sub thread, and call
interrupt on the worker thread if the time expires. The Grinder code is
pretty good about handling interrupts sensibly, but third party code may
not be, so your mileage may vary.

- Phil



------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Philip Aston-3]

Addressing the two problems:

   1. "net.grinder.script.InvalidContextException: No tests have been
      performed by this thread."

      Interesting. This could be because the thread was interrupted
      before the thread entered the Test wrapped code, but that looks
      unlikely in your script.  Can you get me the stack trace of the
      exception that you caught before you called
      getStatisticsForLastTest()?

   2. UncheckedInterruptedExeception

      Your script should be able to catch this and handle it. Use the
      line number in the exception (/mauiWS.py:5929, a call to
      grinder.sleep()) to figure out how its escaping your exception
      handler.

BTW, you should probably reuse the java.util.Timer. (Each Timer creates
its own thread).

- Phil


Tuvell_Walter@... wrote:

> Phil, thank you for your suggestions.  I tried implementing one of them
> (perhaps not exactly the way you had in mind), and am here reporting my
> results.
>
> First, here are some snippets from my Grinder script:
>
>
> . . .
>
> g_appTimeout = 3  # millisec (small, for dev/debug)
>
> . . .
>
> class AppTimeoutException(java.lang.Exception):
>     pass
>
> class AppTimeout(java.util.TimerTask):
>     m_threadId = None
>
>     def __init__(self, i_threadId):
>         self.m_threadId = i_threadId
>
>     def run(self):
>         excep = AppTimeoutException()
>         self.m_threadId.stop(excep)
>
> . . .
>
> def sendReceiveTestRequest(
>     i_msgType, i_proto, i_uri, i_msgContent
> ):
>     . . .
>     try:
>         if g_appTimeout > 0:
>             appTimeout = AppTimeout(java.lang.Thread.currentThread())
>             timer = java.util.Timer()
>             timer.schedule(appTimeout, g_appTimeout)
>
>         testResponse = None  # initialize in case of exception
>         if   i_msgType == 'POST':    # ~ "CREATE"
>             testResponse = i_testRequest.POST(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'GET':     # ~ "READ"
>             testResponse = i_testRequest.GET(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'PUT':     # ~ "UPDATE"
>             testResponse = i_testRequest.PUT(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'DELETE':  # ~ "DELETE"
>             testResponse =
> i_testRequest.DELETE(g_baseUri[i_proto]+i_uri)  # no i_msgContent
>         else:
>             exit(99, '*** INTERNAL ERROR ***')
>
>         if g_appTimeout > 0:
>             timer.cancel()
>
>     except java.lang.Exception:
>         if g_verboseSendRecv:
>             g_sendLock.acquire(); g_numSends-=1; g_sendLock.release();
>         if g_verboseAppTimeout:
>             endTime = java.lang.System.currentTimeMillis()
>             printInfo(i_opName+' APP TIMEOUT FAILURE', i_targetHost,
> i_targetUser,
>                       i_time=endTime-startTime)
>         # Report timeout.
>         #grinder.getStatistics().getForLastTest().setLong("userLong1",
> 1)
>         #grinder.getStatistics().getForLastTest().addLong("userLong2",
> 1)
>         # At this point, because of the exception, this test is marked
> as failed.
>         # So we must reset it to successful, else timeout stats won't
> get reported.
>         #grinder.getStatistics().getForLastTest().setSuccess(True)
>         return 'HANDLEDEXCEPTION'
>     . . .
> }
>
> . . .
>
>
> Note that I had to comment-out the grinder.getStatistics() calls,
> because otherwise I (sometimes) get:
> "net.grinder.script.InvalidContextException: No tests have been
> performed by this thread."  Unfortunately, this means I can't get the
> reports/stats I want (per the comment in the code above).
>
> The above code "works", in the sense that if the Web Service call
> (invocation of i_testRequest.OPERATION()) takes too longer than
> g_appTimeout, then the timer fires and stop()'s the worker thread.
> Otherwise, the timer is cancelled, and the worker proceeds on as usual.
>
> And when I run the above code, it sometimes actually works as hoped.
> But more often (timing-related), I hit some errors.  For a typical run,
> the following is what I got printed out on stdout (Grinder messages are
> interspersed with my own messages) [and, Grinder logfiles are attached]:
>
>
> 9/9/08 5:55:19 PM (process tuvelw490-0): starting threads
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ SEND
>       0_00 00:02.529| TARGETNODE=10.5.115.251  TARGETUSER=userZ
> POOLLEN=14 [BYTES=65]
>          0      1836| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6993f0dc31
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ APP TIMEOUT FAILURE
>       0_00 00:02.537| TARGETNODE=10.5.115.251  TARGETUSER=userZ
>          8         8| TIME=3
> 9/9/08 5:55:21 PM (process tuvelw490-0): There were errors, see
> /tmp/LogGrinder/error_tuvelw490-0.log for full details
> 9/9/08 5:55:21 PM (thread 0 run 0): Aborted run due to Java exception
> calling TestRunner
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ SEND
>       0_00 00:02.547| TARGETNODE=10.5.115.251  TARGETUSER=userX
> POOLLEN=14 [BYTES=65]
>         10        10| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6908a348d5
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ APP TIMEOUT FAILURE
>       0_00 00:02.553| TARGETNODE=10.5.115.251  TARGETUSER=userX
>          6         6| TIME=4
> 9/9/08 5:55:21 PM (process tuvelw490-0): finished
> Exception in thread "Grinder thread 0" java.lang.AssertionError:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
> net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
> atchContext(ThreadContextImplementation.java:279)
> at
> net.grinder.engine.process.ThreadContextImplementation$3.endRun(ThreadCo
> ntextImplementation.java:118)
> at
> net.grinder.engine.process.ThreadContextImplementation$6.inform(ThreadCo
> ntextImplementation.java:176)
> at
> net.grinder.util.ListenerSupport.apply(ListenerSupport.java:92)
> at
> net.grinder.engine.process.ThreadContextImplementation.fireEndRunEvent(T
> hreadContextImplementation.java:174)
> at
> net.grinder.engine.process.GrinderThread.run(GrinderThread.java:142)
> at java.lang.Thread.run(Thread.java:675)
> Caused by:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
> net.grinder.engine.process.TestData$Dispatcher.report(TestData.java:256)
> at
> net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
> atchContext(ThreadContextImplementation.java:276)
> ... 6 more
>
> 9/9/08 5:55:22 PM (agent): finished
>
>
> I remain open to further suggestions.
>
> - Walt
>
>
>
>  
>
> -----Original Message-----
> From: grinder-use-bounces@...
> [mailto:grinder-use-bounces@...] On Behalf Of Philip
> Aston
> Sent: Monday, September 01, 2008 2:31 PM
> To: grinder-use
> Subject: Re: [Grinder-use] Application-level timeouts
>
> Tuvell_Walter@... wrote:
>  
>> I know Grinder supports network-level timeouts:
>> HTTPPluginControl.getConnectionDefaults().setTimeout().
>>
>> But suppose you're using Grinder to test a Web Service that takes a
>>    
> very
>  
>> long time (minute scale) to service requests (either because the
>>    
> service
>  
>> itself is very slow/complicated, or because the server under
>>    
> development
>  
>> is buggy, whatever).  In that case, net-level timeouts aren't
>> applicable, and what you want are app-level time-outs.
>>
>> I tried implementing this, but wasn't successful.  What I tried to do
>> was set a timer in a Worker thread, putting the WS call Grinder
>>    
> request
>  
>> (testRequest.POST(), say) into a sub-thread.  If the WS call returned
>> before the timer fired, then the timer was canceled, and usual Grinder
>> measurements were recorded for the successful call.  If the call took
>> too long and the timer fired first, then the WS call sub-thread was
>> canceled, and the call was recorded as a failure (as a
>>    
> user-configurable
>  
>> statistic).  [I did all this using a try/except construct, but that's
>> irrelevant I think.]
>>
>> But that implementation didn't work.  The problem was that the Grinder
>> framework threw an exception, because it didn't like the Grinder
>>    
> request
>  
>> being done in a sub-thread (it wanted the call to be done in the
>>    
> regular
>  
>> Worker thread).
>>
>> Has anybody tried to do something like app-level timeouts, and been
>> successful, either working around the restriction mentioned above, or
>> using some other technique?
>>
>> Alternatively, would app-level timeouts make a useful enhancement to
>>    
> the
>  
>> Grinder framework itself?
>>
>> - Walt
>>  
>>    
>
> As a workaround, you could make sure everything you do in your "sub
> thread" avoids the use of grinder API's, including Tests. E.g. spawn
> your thread from within a function, and wrap the function in a Test
> rather than the invocation. You'd also have to avoid the HTTPClient
> support (which uses the worker thread as context for storing cookies
> etc.), so that might be unacceptably restrictive.
>
> See what happens if you launch the timer in a sub thread, and call
> interrupt on the worker thread if the time expires. The Grinder code is
> pretty good about handling interrupts sensibly, but third party code may
> not be, so your mileage may vary.
>
> - Phil
>
>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Tuvell_Walter]

/* Apologies for the slowness of my replies, I remain very interested in
this topic, just not interested enough to ignore higher-priority
interrupts ... */

Phil, I have attached (stack.txt) the stack trace you asked for.
[Warning: I use emacs on Linux, so some Win editors might choke.]  The
line number 3608 occurs at the first getStatisticsForLastTest() call in
the excerpt included in this email stream.

As for UncheckedInterruptedExeception, I'm getting an NameError
exception trying to use it, is there something I should be importing?

(About reusing java.util.Timer, thanks, this is just exploration at this
point, I'll clean up after I get it to work as desired.)



 

-----Original Message-----
From: grinder-use-bounces@...
[mailto:grinder-use-bounces@...] On Behalf Of Philip
Aston
Sent: Wednesday, September 10, 2008 5:46 AM
To: grinder-use
Subject: Re: [Grinder-use] Application-level timeouts

Addressing the two problems:

   1. "net.grinder.script.InvalidContextException: No tests have been
      performed by this thread."

      Interesting. This could be because the thread was interrupted
      before the thread entered the Test wrapped code, but that looks
      unlikely in your script.  Can you get me the stack trace of the
      exception that you caught before you called
      getStatisticsForLastTest()?

   2. UncheckedInterruptedExeception

      Your script should be able to catch this and handle it. Use the
      line number in the exception (/mauiWS.py:5929, a call to
      grinder.sleep()) to figure out how its escaping your exception
      handler.

BTW, you should probably reuse the java.util.Timer. (Each Timer creates
its own thread).

- Phil


Tuvell_Walter@... wrote:
> Phil, thank you for your suggestions.  I tried implementing one of
them
> (perhaps not exactly the way you had in mind), and am here reporting
my

> results.
>
> First, here are some snippets from my Grinder script:
>
>
> . . .
>
> g_appTimeout = 3  # millisec (small, for dev/debug)
>
> . . .
>
> class AppTimeoutException(java.lang.Exception):
>     pass
>
> class AppTimeout(java.util.TimerTask):
>     m_threadId = None
>
>     def __init__(self, i_threadId):
>         self.m_threadId = i_threadId
>
>     def run(self):
>         excep = AppTimeoutException()
>         self.m_threadId.stop(excep)
>
> . . .
>
> def sendReceiveTestRequest(
>     i_msgType, i_proto, i_uri, i_msgContent
> ):
>     . . .
>     try:
>         if g_appTimeout > 0:
>             appTimeout = AppTimeout(java.lang.Thread.currentThread())
>             timer = java.util.Timer()
>             timer.schedule(appTimeout, g_appTimeout)
>
>         testResponse = None  # initialize in case of exception
>         if   i_msgType == 'POST':    # ~ "CREATE"
>             testResponse = i_testRequest.POST(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'GET':     # ~ "READ"
>             testResponse = i_testRequest.GET(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'PUT':     # ~ "UPDATE"
>             testResponse = i_testRequest.PUT(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'DELETE':  # ~ "DELETE"
>             testResponse =
> i_testRequest.DELETE(g_baseUri[i_proto]+i_uri)  # no i_msgContent
>         else:
>             exit(99, '*** INTERNAL ERROR ***')
>
>         if g_appTimeout > 0:
>             timer.cancel()
>
>     except java.lang.Exception:
>         if g_verboseSendRecv:
>             g_sendLock.acquire(); g_numSends-=1; g_sendLock.release();
>         if g_verboseAppTimeout:
>             endTime = java.lang.System.currentTimeMillis()
>             printInfo(i_opName+' APP TIMEOUT FAILURE', i_targetHost,
> i_targetUser,
>                       i_time=endTime-startTime)
>         # Report timeout.
>         #grinder.getStatistics().getForLastTest().setLong("userLong1",
> 1)
>         #grinder.getStatistics().getForLastTest().addLong("userLong2",
> 1)
>         # At this point, because of the exception, this test is marked
> as failed.
>         # So we must reset it to successful, else timeout stats won't
> get reported.
>         #grinder.getStatistics().getForLastTest().setSuccess(True)
>         return 'HANDLEDEXCEPTION'
>     . . .
> }
>
> . . .
>
>
> Note that I had to comment-out the grinder.getStatistics() calls,
> because otherwise I (sometimes) get:
> "net.grinder.script.InvalidContextException: No tests have been
> performed by this thread."  Unfortunately, this means I can't get the
> reports/stats I want (per the comment in the code above).
>
> The above code "works", in the sense that if the Web Service call
> (invocation of i_testRequest.OPERATION()) takes too longer than
> g_appTimeout, then the timer fires and stop()'s the worker thread.
> Otherwise, the timer is cancelled, and the worker proceeds on as

usual.
>
> And when I run the above code, it sometimes actually works as hoped.
> But more often (timing-related), I hit some errors.  For a typical

run,
> the following is what I got printed out on stdout (Grinder messages
are
> interspersed with my own messages) [and, Grinder logfiles are
attached]:

>
>
> 9/9/08 5:55:19 PM (process tuvelw490-0): starting threads
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ SEND
>       0_00 00:02.529| TARGETNODE=10.5.115.251  TARGETUSER=userZ
> POOLLEN=14 [BYTES=65]
>          0      1836| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6993f0dc31
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ APP TIMEOUT FAILURE
>       0_00 00:02.537| TARGETNODE=10.5.115.251  TARGETUSER=userZ
>          8         8| TIME=3
> 9/9/08 5:55:21 PM (process tuvelw490-0): There were errors, see
> /tmp/LogGrinder/error_tuvelw490-0.log for full details
> 9/9/08 5:55:21 PM (thread 0 run 0): Aborted run due to Java exception
> calling TestRunner
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ SEND
>       0_00 00:02.547| TARGETNODE=10.5.115.251  TARGETUSER=userX
> POOLLEN=14 [BYTES=65]
>         10        10| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6908a348d5
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ APP TIMEOUT FAILURE
>       0_00 00:02.553| TARGETNODE=10.5.115.251  TARGETUSER=userX
>          6         6| TIME=4
> 9/9/08 5:55:21 PM (process tuvelw490-0): finished
> Exception in thread "Grinder thread 0" java.lang.AssertionError:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
>

net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
> atchContext(ThreadContextImplementation.java:279)
> at
>

net.grinder.engine.process.ThreadContextImplementation$3.endRun(ThreadCo
> ntextImplementation.java:118)
> at
>
net.grinder.engine.process.ThreadContextImplementation$6.inform(ThreadCo
> ntextImplementation.java:176)
> at
> net.grinder.util.ListenerSupport.apply(ListenerSupport.java:92)
> at
>
net.grinder.engine.process.ThreadContextImplementation.fireEndRunEvent(T
> hreadContextImplementation.java:174)
> at
> net.grinder.engine.process.GrinderThread.run(GrinderThread.java:142)
> at java.lang.Thread.run(Thread.java:675)
> Caused by:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
>
net.grinder.engine.process.TestData$Dispatcher.report(TestData.java:256)
> at
>
net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp

> atchContext(ThreadContextImplementation.java:276)
> ... 6 more
>
> 9/9/08 5:55:22 PM (agent): finished
>
>
> I remain open to further suggestions.
>
> - Walt
>
>
>
>  
>
> -----Original Message-----
> From: grinder-use-bounces@...
> [mailto:grinder-use-bounces@...] On Behalf Of Philip
> Aston
> Sent: Monday, September 01, 2008 2:31 PM
> To: grinder-use
> Subject: Re: [Grinder-use] Application-level timeouts
>
> Tuvell_Walter@... wrote:
>  
>> I know Grinder supports network-level timeouts:
>> HTTPPluginControl.getConnectionDefaults().setTimeout().
>>
>> But suppose you're using Grinder to test a Web Service that takes a
>>    
> very
>  
>> long time (minute scale) to service requests (either because the
>>    
> service
>  
>> itself is very slow/complicated, or because the server under
>>    
> development
>  
>> is buggy, whatever).  In that case, net-level timeouts aren't
>> applicable, and what you want are app-level time-outs.
>>
>> I tried implementing this, but wasn't successful.  What I tried to do
>> was set a timer in a Worker thread, putting the WS call Grinder
>>    
> request
>  
>> (testRequest.POST(), say) into a sub-thread.  If the WS call returned
>> before the timer fired, then the timer was canceled, and usual

Grinder

>> measurements were recorded for the successful call.  If the call took
>> too long and the timer fired first, then the WS call sub-thread was
>> canceled, and the call was recorded as a failure (as a
>>    
> user-configurable
>  
>> statistic).  [I did all this using a try/except construct, but that's
>> irrelevant I think.]
>>
>> But that implementation didn't work.  The problem was that the

Grinder

>> framework threw an exception, because it didn't like the Grinder
>>    
> request
>  
>> being done in a sub-thread (it wanted the call to be done in the
>>    
> regular
>  
>> Worker thread).
>>
>> Has anybody tried to do something like app-level timeouts, and been
>> successful, either working around the restriction mentioned above, or
>> using some other technique?
>>
>> Alternatively, would app-level timeouts make a useful enhancement to
>>    
> the
>  
>> Grinder framework itself?
>>
>> - Walt
>>  
>>    
>
> As a workaround, you could make sure everything you do in your "sub
> thread" avoids the use of grinder API's, including Tests. E.g. spawn
> your thread from within a function, and wrap the function in a Test
> rather than the invocation. You'd also have to avoid the HTTPClient
> support (which uses the worker thread as context for storing cookies
> etc.), so that might be unacceptably restrictive.
>
> See what happens if you launch the timer in a sub thread, and call
> interrupt on the worker thread if the time expires. The Grinder code

is
> pretty good about handling interrupts sensibly, but third party code

may
> not be, so your mileage may vary.
>
> - Phil
>
>  



------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use


9/16/08 3:29:05 PM (thread 0 run 0): Aborted run due to Java exception calling TestRunner
Java exception calling TestRunner
        File "/tmp/Grinder/maui-scripts/mauiWS.py", line 3608, in sendReceiveTestRequest
        File "/tmp/Grinder/maui-scripts/mauiWS.py", line 3951, in doREADtest
        File "/tmp/Grinder/maui-scripts/mauiWS.py", line 6291, in __call__
Caused by: net.grinder.script.InvalidContextException: No tests have been performed by this thread.
        at net.grinder.engine.process.ScriptStatisticsImplementation.getForLastTest(ScriptStatisticsImplementation.java:131)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:623)
        at org.python.core.PyReflectedFunction.__call__(Unknown Source)
        at org.python.core.PyMethod.__call__(Unknown Source)
        at org.python.core.PyObject.__call__(Unknown Source)
        at org.python.core.PyInstance.invoke(Unknown Source)
        at org.python.pycode._pyx0.sendReceiveTestRequest$65(/tmp/Grinder/maui-scripts/mauiWS.py:3608)
        at org.python.pycode._pyx0.call_function(/tmp/Grinder/maui-scripts/mauiWS.py)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyFunction.__call__(Unknown Source)
        at org.python.core.PyObject.__call__(Unknown Source)
        at org.python.pycode._pyx0.doREADtest$69(/tmp/Grinder/maui-scripts/mauiWS.py:3951)
        at org.python.pycode._pyx0.call_function(/tmp/Grinder/maui-scripts/mauiWS.py)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyFunction.__call__(Unknown Source)
        at org.python.pycode._pyx0.__call__$111(/tmp/Grinder/maui-scripts/mauiWS.py:6291)
        at org.python.pycode._pyx0.call_function(/tmp/Grinder/maui-scripts/mauiWS.py)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyFunction.__call__(Unknown Source)
        at org.python.core.PyMethod.__call__(Unknown Source)
        at org.python.core.PyObject.invoke(Unknown Source)
        at org.python.core.PyInstance.__call__(Unknown Source)
        at org.python.core.PyObject.__call__(Unknown Source)
        at net.grinder.engine.process.jython.JythonScriptEngine$JythonWorkerRunnable.run(JythonScriptEngine.java:331)
        at net.grinder.engine.process.GrinderThread.run(GrinderThread.java:124)
        at java.lang.Thread.run(Thread.java:675)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use

[Tuvell_Walter]

Never mind, I found it:
net.grinder.common.UncheckedInterruptedException.  And I verified I can
catch it (before java.lang.Exception).

Perhaps that helps to some extent, but I'm still getting the invalid
context exception discussed previously.  I'll run some more tests and
see if that at least eliminates the AssertionError noted earlier.




-----Original Message-----
From: Tuvell, Walter
Sent: Tuesday, September 16, 2008 12:17 PM
To: 'grinder-use'
Subject: RE: [Grinder-use] Application-level timeouts

/* Apologies for the slowness of my replies, I remain very interested in
this topic, just not interested enough to ignore higher-priority
interrupts ... */

Phil, I have attached (stack.txt) the stack trace you asked for.
[Warning: I use emacs on Linux, so some Win editors might choke.]  The
line number 3608 occurs at the first getStatisticsForLastTest() call in
the excerpt included in this email stream.

As for UncheckedInterruptedExeception, I'm getting an NameError
exception trying to use it, is there something I should be importing?

(About reusing java.util.Timer, thanks, this is just exploration at this
point, I'll clean up after I get it to work as desired.)



 

-----Original Message-----
From: grinder-use-bounces@...
[mailto:grinder-use-bounces@...] On Behalf Of Philip
Aston
Sent: Wednesday, September 10, 2008 5:46 AM
To: grinder-use
Subject: Re: [Grinder-use] Application-level timeouts

Addressing the two problems:

   1. "net.grinder.script.InvalidContextException: No tests have been
      performed by this thread."

      Interesting. This could be because the thread was interrupted
      before the thread entered the Test wrapped code, but that looks
      unlikely in your script.  Can you get me the stack trace of the
      exception that you caught before you called
      getStatisticsForLastTest()?

   2. UncheckedInterruptedExeception

      Your script should be able to catch this and handle it. Use the
      line number in the exception (/mauiWS.py:5929, a call to
      grinder.sleep()) to figure out how its escaping your exception
      handler.

BTW, you should probably reuse the java.util.Timer. (Each Timer creates
its own thread).

- Phil


Tuvell_Walter@... wrote:
> Phil, thank you for your suggestions.  I tried implementing one of
them
> (perhaps not exactly the way you had in mind), and am here reporting
my

> results.
>
> First, here are some snippets from my Grinder script:
>
>
> . . .
>
> g_appTimeout = 3  # millisec (small, for dev/debug)
>
> . . .
>
> class AppTimeoutException(java.lang.Exception):
>     pass
>
> class AppTimeout(java.util.TimerTask):
>     m_threadId = None
>
>     def __init__(self, i_threadId):
>         self.m_threadId = i_threadId
>
>     def run(self):
>         excep = AppTimeoutException()
>         self.m_threadId.stop(excep)
>
> . . .
>
> def sendReceiveTestRequest(
>     i_msgType, i_proto, i_uri, i_msgContent
> ):
>     . . .
>     try:
>         if g_appTimeout > 0:
>             appTimeout = AppTimeout(java.lang.Thread.currentThread())
>             timer = java.util.Timer()
>             timer.schedule(appTimeout, g_appTimeout)
>
>         testResponse = None  # initialize in case of exception
>         if   i_msgType == 'POST':    # ~ "CREATE"
>             testResponse = i_testRequest.POST(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'GET':     # ~ "READ"
>             testResponse = i_testRequest.GET(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'PUT':     # ~ "UPDATE"
>             testResponse = i_testRequest.PUT(
> g_baseUri[i_proto]+i_uri, i_msgContent)
>         elif i_msgType == 'DELETE':  # ~ "DELETE"
>             testResponse =
> i_testRequest.DELETE(g_baseUri[i_proto]+i_uri)  # no i_msgContent
>         else:
>             exit(99, '*** INTERNAL ERROR ***')
>
>         if g_appTimeout > 0:
>             timer.cancel()
>
>     except java.lang.Exception:
>         if g_verboseSendRecv:
>             g_sendLock.acquire(); g_numSends-=1; g_sendLock.release();
>         if g_verboseAppTimeout:
>             endTime = java.lang.System.currentTimeMillis()
>             printInfo(i_opName+' APP TIMEOUT FAILURE', i_targetHost,
> i_targetUser,
>                       i_time=endTime-startTime)
>         # Report timeout.
>         #grinder.getStatistics().getForLastTest().setLong("userLong1",
> 1)
>         #grinder.getStatistics().getForLastTest().addLong("userLong2",
> 1)
>         # At this point, because of the exception, this test is marked
> as failed.
>         # So we must reset it to successful, else timeout stats won't
> get reported.
>         #grinder.getStatistics().getForLastTest().setSuccess(True)
>         return 'HANDLEDEXCEPTION'
>     . . .
> }
>
> . . .
>
>
> Note that I had to comment-out the grinder.getStatistics() calls,
> because otherwise I (sometimes) get:
> "net.grinder.script.InvalidContextException: No tests have been
> performed by this thread."  Unfortunately, this means I can't get the
> reports/stats I want (per the comment in the code above).
>
> The above code "works", in the sense that if the Web Service call
> (invocation of i_testRequest.OPERATION()) takes too longer than
> g_appTimeout, then the timer fires and stop()'s the worker thread.
> Otherwise, the timer is cancelled, and the worker proceeds on as

usual.
>
> And when I run the above code, it sometimes actually works as hoped.
> But more often (timing-related), I hit some errors.  For a typical
run,
> the following is what I got printed out on stdout (Grinder messages
are
> interspersed with my own messages) [and, Grinder logfiles are
attached]:

>
>
> 9/9/08 5:55:19 PM (process tuvelw490-0): starting threads
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ SEND
>       0_00 00:02.529| TARGETNODE=10.5.115.251  TARGETUSER=userZ
> POOLLEN=14 [BYTES=65]
>          0      1836| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6993f0dc31
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=0
> SOAP_READ APP TIMEOUT FAILURE
>       0_00 00:02.537| TARGETNODE=10.5.115.251  TARGETUSER=userZ
>          8         8| TIME=3
> 9/9/08 5:55:21 PM (process tuvelw490-0): There were errors, see
> /tmp/LogGrinder/error_tuvelw490-0.log for full details
> 9/9/08 5:55:21 PM (thread 0 run 0): Aborted run due to Java exception
> calling TestRunner
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ SEND
>       0_00 00:02.547| TARGETNODE=10.5.115.251  TARGETUSER=userX
> POOLLEN=14 [BYTES=65]
>         10        10| OUTSTANDINGSENDS=1
> OBJID=5ca1ab1e0a0573fc048c69019228e3048c6908a348d5
>
> 2008-09-09T17:55:21Z| WORKER=tuvelw490-0  THREAD=0   RUNNUM=1
> REST_READ APP TIMEOUT FAILURE
>       0_00 00:02.553| TARGETNODE=10.5.115.251  TARGETUSER=userX
>          6         6| TIME=4
> 9/9/08 5:55:21 PM (process tuvelw490-0): finished
> Exception in thread "Grinder thread 0" java.lang.AssertionError:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
>

net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp
> atchContext(ThreadContextImplementation.java:279)
> at
>
net.grinder.engine.process.ThreadContextImplementation$3.endRun(ThreadCo
> ntextImplementation.java:118)
> at
>
net.grinder.engine.process.ThreadContextImplementation$6.inform(ThreadCo
> ntextImplementation.java:176)
> at
> net.grinder.util.ListenerSupport.apply(ListenerSupport.java:92)
> at
>
net.grinder.engine.process.ThreadContextImplementation.fireEndRunEvent(T
> hreadContextImplementation.java:174)
> at
> net.grinder.engine.process.GrinderThread.run(GrinderThread.java:142)
> at java.lang.Thread.run(Thread.java:675)
> Caused by:
> net.grinder.engine.process.DispatchContext$DispatchStateException: No
> statistics to report
> at
>
net.grinder.engine.process.TestData$Dispatcher.report(TestData.java:256)
> at
>
net.grinder.engine.process.ThreadContextImplementation.reportPendingDisp

> atchContext(ThreadContextImplementation.java:276)
> ... 6 more
>
> 9/9/08 5:55:22 PM (agent): finished
>
>
> I remain open to further suggestions.
>
> - Walt
>
>
>
>  
>
> -----Original Message-----
> From: grinder-use-bounces@...
> [mailto:grinder-use-bounces@...] On Behalf Of Philip
> Aston
> Sent: Monday, September 01, 2008 2:31 PM
> To: grinder-use
> Subject: Re: [Grinder-use] Application-level timeouts
>
> Tuvell_Walter@... wrote:
>  
>> I know Grinder supports network-level timeouts:
>> HTTPPluginControl.getConnectionDefaults().setTimeout().
>>
>> But suppose you're using Grinder to test a Web Service that takes a
>>    
> very
>  
>> long time (minute scale) to service requests (either because the
>>    
> service
>  
>> itself is very slow/complicated, or because the server under
>>    
> development
>  
>> is buggy, whatever).  In that case, net-level timeouts aren't
>> applicable, and what you want are app-level time-outs.
>>
>> I tried implementing this, but wasn't successful.  What I tried to do
>> was set a timer in a Worker thread, putting the WS call Grinder
>>    
> request
>  
>> (testRequest.POST(), say) into a sub-thread.  If the WS call returned
>> before the timer fired, then the timer was canceled, and usual

Grinder

>> measurements were recorded for the successful call.  If the call took
>> too long and the timer fired first, then the WS call sub-thread was
>> canceled, and the call was recorded as a failure (as a
>>    
> user-configurable
>  
>> statistic).  [I did all this using a try/except construct, but that's
>> irrelevant I think.]
>>
>> But that implementation didn't work.  The problem was that the

Grinder

>> framework threw an exception, because it didn't like the Grinder
>>    
> request
>  
>> being done in a sub-thread (it wanted the call to be done in the
>>    
> regular
>  
>> Worker thread).
>>
>> Has anybody tried to do something like app-level timeouts, and been
>> successful, either working around the restriction mentioned above, or
>> using some other technique?
>>
>> Alternatively, would app-level timeouts make a useful enhancement to
>>    
> the
>  
>> Grinder framework itself?
>>
>> - Walt
>>  
>>    
>
> As a workaround, you could make sure everything you do in your "sub
> thread" avoids the use of grinder API's, including Tests. E.g. spawn
> your thread from within a function, and wrap the function in a Test
> rather than the invocation. You'd also have to avoid the HTTPClient
> support (which uses the worker thread as context for storing cookies
> etc.), so that might be unacceptably restrictive.
>
> See what happens if you launch the timer in a sub thread, and call
> interrupt on the worker thread if the time expires. The Grinder code

is
> pretty good about handling interrupts sensibly, but third party code
may
> not be, so your mileage may vary.
>
> - Phil
>
>  



------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use