|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
|
| Hi, I didn't get any reply for my query of recording desktop based Swing application. Is there any separate plugin available. As of now Grinder3 is mature enough to record HTTP level. But I have a Swing application in which the Rich client talks to the Server ... Any help would be appreciated. Regards, Rahman --- On Tue, 1/9/09, grinder-use-request@... <grinder-use-request@...> wrote:
|
Hi,
I didn't get any reply for my query of recording desktop based Swing application.
Is there any separate plugin available. As of now Grinder3 is mature enough to record HTTP level. But I have a Swing application in which the Rich client talks to the Server ... Any help would be appreciated.
Regards,
Rahman
--- On Tue, 1/9/09, grinder-use-request@... <grinder-use-request@...> wrote:
From: grinder-use-request@... <grinder-use-request@...>
Subject: grinder-use Digest, Vol 40, Issue 1
To: grinder-use@...
Date: Tuesday, 1 September, 2009, 10:22 PM
Send grinder-use mailing list submissions to
grinder-use@... </mc/compose?to=grinder-use@...>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/grinder-use
or, via email, send a message with subject or body 'help' to
grinder-use-request@... </mc/compose?to=grinder-use-request@...>
You can reach the person managing the list at
grinder-use-owner@... </mc/compose?to=grinder-use-owner@...>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grinder-use digest..."
Today's Topics:
1. Re: What does it mean when Grinder threads die?
(Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> )
2. Testing Desktop Application (working freak)
3. Re: What does it mean when Grinder threads die? (Philip Aston)
4. Re: Testing Desktop Application (Anirvan Majumdar)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Sep 2009 07:14:26 -0400
From: <Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> >
Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
To: <grinder-use@... </mc/compose?to=grinder-use@...> >
Message-ID:
<0F3F903BA6B4A54984787888AF6EA5C4036F2375@... </mc/compose?to=0F3F903BA6B4A54984787888AF6EA5C4036F2375@...> >
Content-Type: text/plain; charset="us-ascii"
I ran another overnight test, and encountered the dying-threads
situation again. This time, I've captured the logfiles (out, data, and
my private logfile, but no error logfile was produced), and a couple of
screenshots. They're too big/boring to post here, but the summary is
that one agent (of 4) had only 48 (of 50) threads still existing, and a
jstack shows that threads # 19 & 47 have disappeared. [I'm actively
developing the Grinder driver-script, so some unhandled exception
"Errors" have filtered through to the GUI, contrary to my normal
practice as mentioned previously, but they don't seem to be contributing
to this issue.] The other 3 Agents involved in the test still had all
50 threads active throughout the test.
But, I don't really know where to go from here. The out logfile shows
nothing interesting, while the data logfile (and my private logfile,
which wasn't set to its highest level of logging, but that's
inconsequential) shows the two dead threads worked for about half the
test period, then simply stopped producing output prematurely, doing
different tests -- but both at exactly the same instant (timestamp
1251531335803)!
Help, Phil?
- Walt
-----Original Message-----
From: Tuvell, Walter
Sent: Friday, August 14, 2009 1:51 PM
To: 'grinder-use'
Subject: RE: [Grinder-use] What does it mean when Grinder threads die?
Understand. There is "nowhere" (I claim) in my script where a worker
thread can throw an unhandled exception to the framework. That's
because I handle all exceptions that can be thrown by the worker threads
myself, and turn them into my own error msgs and GUI columns. Nothing
showed in the GUI.
Stack-blowing is a good idea, but probably not the answer. I indeed
have no recursion (if you exclude a guaranteed single-level recursion in
a small function I have in one place, for convenience), but I do keep
the stack size at a nice compact -Xss96k. That value was arrived at by
calibration experiments (plus a buffer), as you might expect, and if it
were insufficient I'd expect it to show up regularly even in short
tests. Many multi-day tests succeed, only some fail (with the same
config params). Since the code is highly deterministic (at least as
regards dynamic code paths including stack depth), it's hard to see how
that could be the problem. But a re-calibration is in order.
-----Original Message-----
From: Philip Aston [philip.aston@... </mc/compose?to=philip.aston@...> ]
Sent: Friday, August 14, 2009 1:32 PM
To: grinder-use
Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
If a thread exited due to an unexpected exception (i.e. anything other
than shutdown), this should have been logged.
Do you have any recursive code? I wonder whether there's an outside
chance the threads are blowing their stack and dying quietly.
- Phil
Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> wrote:
> I did have runs=0, and the threads did indeed exist at the start of
the
> test, then disappeared sometime overnight.
>
> There was nothing interesting in the error_*-N.log file, and I had
> out_*-N.log and data_*-N.log turned off. However, I write my own
(very
> extensive) logfile, and there was nothing interesting in it either, at
> least not that I saw after a cursory examination. But the logfile was
>
>> 1G, and I didn't search with diligence. Had I done so, I could have
>>
> figured out exactly which threads died, and what their last action was
> (at least at script level).
>
> I don't have those records any more, but I'll keep an eye out for
this,
> and when/if it happens again I'll contact you.
>
> Thx.
>
> - Walt
>
>
>
>
> -----Original Message-----
> From: Philip Aston [philip.aston@... </mc/compose?to=philip.aston@...> ]
> Sent: Friday, August 14, 2009 1:09 PM
> To: grinder-use
> Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
>
> The threads must have exited. Assuming you have runs=0, this is hard
for
> a single thread to achieve.
>
> Does the error log give any hint?
>
> - Phil
>
> Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> wrote:
>
>> During multi-day tests, I sometimes see Grinder threads die. What
>>
> does
>
>> it mean?
>>
>> For example, yesterday I started a test with grinder.threads=12.
This
>> morning, after running overnight, only 1 thread ("Grinder thread 5")
>>
> was
>
>> still alive, as shown both by the Grinder GUI ("Running 1/12
>>
> threads"),
>
>> as well as the attached jstack dump (which shows nothing else
>> suspicious, insofar as I can tell). The one live thread was happily
>> going about its business (sending/receiving tests to the server), and
>>
> no
>
>> problems were posted in the Grinder GUI or in the logfile.
>>
>> In fact during this test, there were 4 Agent machines. Besides the
>>
> one
>
>> just discussed, another one had 10 threads still running (2 died),
>>
> while
>
>> the other 2 had all 12 threads running. And the Console machine
>>
> seemed
>
>> just fine, too.
>>
>> What's happening?
>>
>>
>> <<deadThreads.txt>>
>>
>>
>>
>>
>
------------------------------------------------------------------------
>
>>
>
------------------------------------------------------------------------
> ------
>
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>
> 30-Day
>
>> trial. Simplify your report design, integration and deployment - and
>>
> focus on
>
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>
>>
>
------------------------------------------------------------------------
>
>> _______________________________________________
>> grinder-use mailing list
>> grinder-use@... </mc/compose?to=grinder-use@...>
>> https://lists.sourceforge.net/lists/listinfo/grinder-use
>>
------------------------------
Message: 2
Date: Tue, 1 Sep 2009 16:57:05 +0530 (IST)
From: working freak <working_freak@... </mc/compose?to=working_freak@...> >
Subject: [Grinder-use] Testing Desktop Application
To: grinder-use@... </mc/compose?to=grinder-use@...>
Message-ID: <432348.72876.qm@... </mc/compose?to=432348.72876.qm@...> >
Content-Type: text/plain; charset="utf-8"
Hi All,
I have a desktop application which is not connected to the internet. I want to check the transaction timings for each transaction I do. Is it possible to do it using The Grinder. If Yes please guide me.
Regards,
Rahman.
See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Tue, 01 Sep 2009 15:46:58 +0100
From: Philip Aston <philip.aston@... </mc/compose?to=philip.aston@...> >
Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
To: grinder-use <grinder-use@... </mc/compose?to=grinder-use@...> >
Message-ID: <4A9D33E2.3050309@... </mc/compose?to=4A9D33E2.3050309@...> >
Content-Type: text/plain; charset=UTF-8
Perhaps registering an exception listener with
Thread.setDefaultUncaughtExceptionHandler() will tell you something?
- Phil
Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> wrote:
> I ran another overnight test, and encountered the dying-threads
> situation again. This time, I've captured the logfiles (out, data, and
> my private logfile, but no error logfile was produced), and a couple of
> screenshots. They're too big/boring to post here, but the summary is
> that one agent (of 4) had only 48 (of 50) threads still existing, and a
> jstack shows that threads # 19 & 47 have disappeared. [I'm actively
> developing the Grinder driver-script, so some unhandled exception
> "Errors" have filtered through to the GUI, contrary to my normal
> practice as mentioned previously, but they don't seem to be contributing
> to this issue.] The other 3 Agents involved in the test still had all
> 50 threads active throughout the test.
>
> But, I don't really know where to go from here. The out logfile shows
> nothing interesting, while the data logfile (and my private logfile,
> which wasn't set to its highest level of logging, but that's
> inconsequential) shows the two dead threads worked for about half the
> test period, then simply stopped producing output prematurely, doing
> different tests -- but both at exactly the same instant (timestamp
> 1251531335803)!
>
> Help, Phil?
>
> - Walt
>
>
>
>
> -----Original Message-----
> From: Tuvell, Walter
> Sent: Friday, August 14, 2009 1:51 PM
> To: 'grinder-use'
> Subject: RE: [Grinder-use] What does it mean when Grinder threads die?
>
> Understand. There is "nowhere" (I claim) in my script where a worker
> thread can throw an unhandled exception to the framework. That's
> because I handle all exceptions that can be thrown by the worker threads
> myself, and turn them into my own error msgs and GUI columns. Nothing
> showed in the GUI.
>
> Stack-blowing is a good idea, but probably not the answer. I indeed
> have no recursion (if you exclude a guaranteed single-level recursion in
> a small function I have in one place, for convenience), but I do keep
> the stack size at a nice compact -Xss96k. That value was arrived at by
> calibration experiments (plus a buffer), as you might expect, and if it
> were insufficient I'd expect it to show up regularly even in short
> tests. Many multi-day tests succeed, only some fail (with the same
> config params). Since the code is highly deterministic (at least as
> regards dynamic code paths including stack depth), it's hard to see how
> that could be the problem. But a re-calibration is in order.
>
>
>
> -----Original Message-----
> From: Philip Aston [philip.aston@... </mc/compose?to=philip.aston@...> ]
> Sent: Friday, August 14, 2009 1:32 PM
> To: grinder-use
> Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
>
> If a thread exited due to an unexpected exception (i.e. anything other
> than shutdown), this should have been logged.
>
> Do you have any recursive code? I wonder whether there's an outside
> chance the threads are blowing their stack and dying quietly.
>
> - Phil
>
> Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> wrote:
>
>> I did have runs=0, and the threads did indeed exist at the start of
>>
> the
>
>> test, then disappeared sometime overnight.
>>
>> There was nothing interesting in the error_*-N.log file, and I had
>> out_*-N.log and data_*-N.log turned off. However, I write my own
>>
> (very
>
>> extensive) logfile, and there was nothing interesting in it either, at
>> least not that I saw after a cursory examination. But the logfile was
>>
>>
>>> 1G, and I didn't search with diligence. Had I done so, I could have
>>>
>>>
>> figured out exactly which threads died, and what their last action was
>> (at least at script level).
>>
>> I don't have those records any more, but I'll keep an eye out for
>>
> this,
>
>> and when/if it happens again I'll contact you.
>>
>> Thx.
>>
>> - Walt
>>
>>
>>
>>
>> -----Original Message-----
>> From: Philip Aston [philip.aston@... </mc/compose?to=philip.aston@...> ]
>> Sent: Friday, August 14, 2009 1:09 PM
>> To: grinder-use
>> Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
>>
>> The threads must have exited. Assuming you have runs=0, this is hard
>>
> for
>
>> a single thread to achieve.
>>
>> Does the error log give any hint?
>>
>> - Phil
>>
>> Tuvell_Walter@... </mc/compose?to=Tuvell_Walter@...> wrote:
>>
>>
>>> During multi-day tests, I sometimes see Grinder threads die. What
>>>
>>>
>> does
>>
>>
>>> it mean?
>>>
>>> For example, yesterday I started a test with grinder.threads=12.
>>>
> This
>
>>> morning, after running overnight, only 1 thread ("Grinder thread 5")
>>>
>>>
>> was
>>
>>
>>> still alive, as shown both by the Grinder GUI ("Running 1/12
>>>
>>>
>> threads"),
>>
>>
>>> as well as the attached jstack dump (which shows nothing else
>>> suspicious, insofar as I can tell). The one live thread was happily
>>> going about its business (sending/receiving tests to the server), and
>>>
>>>
>> no
>>
>>
>>> problems were posted in the Grinder GUI or in the logfile.
>>>
>>> In fact during this test, there were 4 Agent machines. Besides the
>>>
>>>
>> one
>>
>>
>>> just discussed, another one had 10 threads still running (2 died),
>>>
>>>
>> while
>>
>>
>>> the other 2 had all 12 threads running. And the Console machine
>>>
>>>
>> seemed
>>
>>
>>> just fine, too.
>>>
>>> What's happening?
>>>
>>>
>>> <<deadThreads.txt>>
>>>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>
>>
>>
>>>
>>>
> ------------------------------------------------------------------------
>
>> ------
>>
>>
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>
>>>
>> 30-Day
>>
>>
>>> trial. Simplify your report design, integration and deployment - and
>>>
>>>
>> focus on
>>
>>
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>>
>>>
>>>
> ------------------------------------------------------------------------
>
>>
>>
>>> _______________________________________________
>>> grinder-use mailing list
>>> grinder-use@... </mc/compose?to=grinder-use@...>
>>> https://lists.sourceforge.net/lists/listinfo/grinder-use
>>>
>>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> grinder-use mailing list
> grinder-use@... </mc/compose?to=grinder-use@...>
> https://lists.sourceforge.net/lists/listinfo/grinder-use
>
------------------------------
Message: 4
Date: Tue, 1 Sep 2009 22:22:12 +0530
From: "Anirvan Majumdar" <anirvan.majumdar@... </mc/compose?to=anirvan.majumdar@...> >
Subject: Re: [Grinder-use] Testing Desktop Application
To: "'grinder-use'" <grinder-use@... </mc/compose?to=grinder-use@...> >
Message-ID: <4a9d5142.01145e0a.0567.1dde@... </mc/compose?to=4a9d5142.01145e0a.0567.1dde@...> >
Content-Type: text/plain; charset="utf-8"
It actually depends if your desktop application is Java based? I know how to probably work that out, but won?t be of much assistance if it?s written in C/++ or some other language.
From: working freak [working_freak@... </mc/compose?to=working_freak@...> ]
Sent: 01 September 2009 16:57
To: grinder-use@... </mc/compose?to=grinder-use@...>
Subject: [Grinder-use] Testing Desktop Application
Hi All,
I have a desktop application which is not connected to the internet. I want to check the transaction timings for each transaction I do. Is it possible to do it using The Grinder. If Yes please guide me.
Regards,
Rahman.
_____
See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz <http://in.rd.yahoo.com/tagline_buzz_1/*http:/in.buzz.yahoo.com/> .
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------
_______________________________________________
grinder-use mailing list
grinder-use@... </mc/compose?to=grinder-use@...>
https://lists.sourceforge.net/lists/listinfo/grinder-use
End of grinder-use Digest, Vol 40, Issue 1
******************************************
See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz <http://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/> .
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
| Free embeddable forum powered by Nabble | Forum Help |