[prev in list] [next in list] [prev in thread] [next in thread]
List: grinder-development
Subject: [Grinder-development] [ grinder-Bugs-2992248 ] New Instrumentation
From: "SourceForge.net" <noreply () sourceforge ! net>
Date: 2011-07-31 11:47:10
Message-ID: E1QnUUC-0005CL-9L () sfs-ml-3 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]
Bugs item #2992248, was opened at 2010-04-26 11:05
Message generated for change (Comment added) made by philipa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2992248&group_id=18598
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core engine
Group: None
> Status: Closed
> Resolution: Fixed
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Philip Aston (philipa)
Summary: New Instrumentation method not working for 'record'
Initial Comment:
I have downloaded Grinder 3.4 and installed on a Windows 2003 server, with \
Jython2.5.1 and Java sdk jdk1.6.0_20
When I run the sample helloworld script (as listed at the end of this email) which \
uses the 'record' method for instrumentation it seems that although the log file is \
being written to, however the Console does not get any aggregated data when using \
‘record' No data is written to the data file (example: data_gwydlg030322-0.log)
If we use the older ‘wrap' method with the new instrumentation all works ok.
We see certain text in the log file proving that it is using the new instrumentation:
instrumentation agents: byte code transforming instrumenter for Jython 2.5; byte code \
transforming instrumenter…. 4/21/10 11:34:05 AM (thread 5 run 22): Hello World
4/21/10 11:34:05 AM (thread 6 run 3): Hello World
Any help greatly appreciated
/Kevin
ps Via the grinder.properties we set the instrumentation to the new version: \
ingrinder.dcrinstrumentation: true Helloworld.py
from net.grinder.script import Test
from net.grinder.script.Grinder import grinder
test1 = Test(1, "Log method")
# Instrument the output() method with our Test.
test1.record(grinder.logger.output)
class TestRunner:
def __call__(self):
grinder.logger.output("Hello World")
------------------------
Kevin,
You're right - it appears the new instrumentation is not working for
Java functions. Its working for other things, e.g. you should find the
following works:
from net.grinder.script import Test
from net.grinder.script.Grinder import grinder
test1 = Test(1, "Log method")
# Instrument the output() method with our Test.
def foo(x):
grinder.logger.output(x)
test1.record(foo)
class TestRunner:
def __call__(self):
foo("Hello World")
Apologies for not trying this immediately. Dave - thanks for the
confirmation.
Please open a bug report on the sourceforge website.
- Phil
----------------------------------------------------------------------
> Comment By: Philip Aston (philipa)
Date: 2011-07-31 12:47
Message:
I found a way to instrument the underlying Java methods. This bug is now
properly fixed, and will be released with the next version of The Grinder.
http://grinder.svn.sourceforge.net/viewvc/grinder?view=revision&revision=4284
Note, the original test case won't pass, but for a different reason. The
DCR instrumenter cannot instrument classes within the
net.grinder.engine.process package.
The draft documentation attached to this bug report describes the
situation in The Grinder 3.3 and 3.4, but will not apply to The Grinder
3.5.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2011-07-29 14:53
Message:
Corrected draft documentation: the various subtleties only apply to Java
methods.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2011-07-28 22:06
Message:
I've spent a few days looking at this, and I'm closing it as "won't fix".
The behaviour is actually reasonable. Its not (as I thought earlier)
anything to do with Jython bypassing the instrumentation. The problem is
that there are multiple Jython proxy objects, and it is the proxy that is
instrumented, not the underlying method. Once yuo understand the problem,
its not too tricky to work around it. The sad thing is that it exposes the
cracks between Java and Jython.
Arguably, the Jython instrumentation would be more powerful if it could
identify the underlying method and instrument that. This would also be
useful to do for Java classes and instances, since it would allow the
instrumentation to work if these were record'ed in Jython, then invoked in
Java. Unfortunately, there's no easy way to achieve this using the Jython
internal APIs, especially in a way that works generically across all Jython
versions.
I've written some documentation to help script authors understand the
problem. This will be included when I release the docs for the next
version. I've attached a draft to this bug report.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-05-29 16:17
Message:
This is frustrating, since the reason for the bytecode based
instrumentation is to reduce coupling to Jython.
We need to investigate whether something smart could be returned from
wrap(). E.g. recreate a Jython proxy to the method and return that. This
might provide a workaround for Java methods.
In general, perhaps we should support wrap() style semantics as an
alternative for record() (which is still required for statically linked
Java) where we dynamically create a proxy object and instrument that
instead.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-04-29 21:00
Message:
I believe the instrumentation is actually working fine, but the problem is
that Jython 2.5.1 has some deeper byte code binding to the original version
of the output method.
Can you confirm that the original script
(http://grinder.sourceforge.net/g3/script-gallery.html#helloworld) works
with the new instrumentation? I.e. using the result of calling wrap(),
rather than the new record() method?
Thanks.
- Phil
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2992248&group_id=18598
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Grinder-development mailing list
Grinder-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-development
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic