[ grinder-Bugs-2936167 ] Script execution hangs when using jython 2.5.1 and windows
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.comp.java.grinder.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #2936167, was opened at 2010-01-21 09:32
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2936167&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Philip Aston (philipa)
Summary: Script execution hangs when using jython 2.5.1 and windows
Initial Comment:
When adding jython into the classpath of the agent the process hangs and will only repsond to ctrl-c
The script then continue to run.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-26 15:34
Message:
I moved grinder-agent.jar out of the grinder lib, made sure it was not
picked up on the classpath. With jython.jar in the classpath then started
the agent and it hung up.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-24 20:05
Message:
Another quick test you could run. Can you try moving the grinder-agent.jar
file out of the lib directory to somewhere not on the classpath, and
starting with Jython 2.5 in the classpath. This will determine whether the
problem is the agent/instrumentation or Jython 2.5.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-24 19:16
Message:
Sorry - looks like grinder.debug.singleprocess doesn't work with the new
instrumentation. I've opened bug 2958145 to track that problem.
However, that the script runs means you got much further than with a
separate worker process. Looks like the problem is related to Windows and
process streams. But my guesses at how to trigger it to date have all
failed.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-24 14:13
Message:
I have tried running with grinder.debug.singleprocess set to true, it
actually does get into my test script but barfs when calling record(). I
have grinder.dcrinstrumentation=true and have added all the jars from
grinder lib to my classpath. You can see start of out log and stack trace
from err log below:
2/24/10 7:57:41 AM (process MOTLABRGATE001-0): The Grinder version 3.3
2/24/10 7:57:41 AM (process MOTLABRGATE001-0): Java(TM) SE Runtime
Environment 1.6.0_18-b07: Java HotSpot(TM) Client VM (16.0-b13, mixed mode,
sharing) on Windows 2003 x86 5.2
2/24/10 7:57:41 AM (process MOTLABRGATE001-0): time zone is CST (-0600)
2/24/10 7:57:42 AM (process MOTLABRGATE001-0): worker process 0
2/24/10 7:57:42 AM (process MOTLABRGATE001-0): instrumentation agents: NO
INSTRUMENTER COULD BE LOADED
2/24/10 7:57:42 AM (process MOTLABRGATE001-0): executing "mstvdiag.py"
using Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)]
2/24/10 7:57:45 AM (process MOTLABRGATE001-0): starting threads
2/24/10 7:57:45 AM (thread 0): starting, will do 1 run
2/24/10 7:57:45 AM (process MOTLABRGATE001-0): start time is 1267019865558
ms since Epoch
2/24/10 7:57:45 AM (thread 0 run 0): ERROR ("Aborted run due to J..."),
see error log for details
2/24/10 7:57:45 AM (thread 0): finished 1 run
2/24/10 7:57:45 AM (process MOTLABRGATE001-0): elapsed time is 22 ms
2/24/10 7:59:57 AM (thread 0 run 0): Aborted run due to Java exception
calling TestRunner
Java exception calling TestRunner
test1.record(xapi)
File ".\mstvdiag.py", line 21, in __call__
Caused by: net.grinder.script.NonInstrumentableTypeException: Failed to
wrap XApiClient {url: http://172.16.203.217:8080/nbbs5/api, username:
admin}
at
net.grinder.engine.process.instrumenter.MasterInstrumenter.instrument(MasterInstrumenter.java:109)
at net.grinder.engine.process.TestData.instrument(TestData.java:100)
at net.grinder.script.Test.record(Test.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:175)
at org.python.core.PyObject.__call__(PyObject.java:355)
at org.python.core.PyMethod.__call__(PyMethod.java:215)
at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221)
at org.python.core.PyMethod.__call__(PyMethod.java:206)
at org.python.core.PyObject.__call__(PyObject.java:397)
at org.python.core.PyObject.__call__(PyObject.java:401)
at org.python.pycode._pyx0.__call__$3(.\mstvdiag.py:72)
at org.python.pycode._pyx0.call_function(.\mstvdiag.py)
at org.python.core.PyTableCode.call(PyTableCode.java:165)
at org.python.core.PyBaseCode.call(PyBaseCode.java:297)
at org.python.core.PyBaseCode.call(PyBaseCode.java:191)
at org.python.core.PyFunction.__call__(PyFunction.java:385)
at org.python.core.PyMethod.__call__(PyMethod.java:215)
at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221)
at org.python.core.PyMethod.__call__(PyMethod.java:206)
at org.python.core.PyObject.invoke(PyObject.java:3553)
at org.python.core.PyInstance.instance___call__(PyInstance.java:336)
at org.python.core.PyInstance.__call__(PyInstance.java:327)
at org.python.core.PyObject.__call__(PyObject.java:381)
at
net.grinder.engine.process.jython.JythonScriptEngine$JythonWorkerRunnable.run(JythonScriptEngine.java:193)
at net.grinder.engine.process.GrinderThread.run(GrinderThread.java:131)
at java.lang.Thread.run(Thread.java:619)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-24 14:08
Message:
Attempt 3 - Test - No hang:
C:\Temp\mark\grinder-test>java -cp test3.jar;grinder-agent.jar;jython.jar;
test.Parent
[parent] Starting [java, -javaagent:grinder-agent.jar, -classpath,
test3.jar;grinder-agent.jar;jython.jar;, test.Child]
[parent] Writing a message to the child stdin
[parent] Waiting
[child] Reading a message from stdin
[child] Initializing Jython
*sys-package-mgr*: processing new jar,
'C:\Temp\mark\grinder-test\test3.jar'
[child] Executing Jython
Hello world
[child] Done
[parent] Done, process exit code: 0
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-24 08:27
Message:
Attempt 3 - also needs the agent jar to be in the working directory.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-24 08:18
Message:
To rule process interaction in or out, please try running The Grinder with
the property grinder.debug.singleprocess set to true.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-23 02:05
Message:
Still no hang:
C:\Temp\mark\grinder-test>java -cp grinder-agent.jar;jython.jar;test2.jar;
test.Parent
[parent] Starting [java, -javaagent:grinder-agent.jar, -classpath,
grinder-agent.jar;jython.jar;test2.jar;, test.Child]
[parent] Waiting
[child] Initializing Jython
*sys-package-mgr*: processing new jar,
'C:\Temp\mark\grinder-test\grinder-agent.jar'
*sys-package-mgr*: processing new jar,
'C:\Temp\mark\grinder-test\test2.jar'
[child] Executing Jython
Hello world
[child] Done
[parent] Done, process exit code: 0
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-22 20:35
Message:
Second guess: I've modified the test code to also start the Java agent.
To use, please copy grinder-agent.jar from a recent grinder distribution
(in the lib directory) to the local directory, then run as before, e.g.
% java -cp test2.jar:/opt/jython/jython2.5.1/jython.jar test.Parent
[parent] Starting [java, -javaagent:grinder-agent.jar, -classpath,
test2.jar:/opt/jython/jython2.5.1/jython.jar, test.Child]
[parent] Waiting
[child] Initializing Jython
*sys-package-mgr*: processing modified jar,
'/home/philipa/grinder/bugs/bug2936167/test2.jar'
[child] Executing Jython
Hello world
[child] Done
[parent] Done, process exit code: 0
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-22 20:29
Message:
[Discussion about the first test case]
Phil,
Not what you wanted to hear, but it did not hang up on my Windows 2003
box. See output below, along with jython and java version stamps. Also note
that I am only having problems on my Windows 2003 box that I have to run
the agent on (unfortunately). I have not had any issues on Windows XP or
Windows 7 while developing my grinder test script.
C:\Temp\mark\grinder-test>java -cp test.jar;jython.jar test.Parent
[parent] Starting [java, -classpath, test.jar;jython.jar, test.Child]
[parent] Waiting
[child] Initializing Jython
[child] Executing Jython
Hello world
[child] Done
[parent] Done, process exit code: 0
C:\Temp\mark\grinder-test>java -jar jython.jar --version
Jython 2.5.1
C:\Temp\mark\grinder-test>java -version
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
Mark
-----Original Message-----
From: Philip Aston [mailto:[email protected]]
Sent: Monday, February 22, 2010 1:45 AM
To: grinder-use
Subject: Re: [Grinder-use] Grinder 3.3 and jython 2.5.1
Mark,
I've attached a test case. Can you trying running this as follows:
java -cp test.jar;c:jython2.5.1/jython.jar test.Parent
Use Java 6, and adjust the path to your jython.jar appropriately. If it
works, as it always does for me under Linux, you'll see output similar to
the following:
[parent] Starting [java, -classpath,
test.jar:/opt/jython/jython2.5.1/jython.jar, test.Child]
[parent] Waiting
[child] Initializing Jython
*sys-package-mgr*: processing modified jar,
'/home/philipa/grinder/bugs/bug2936167/test.jar'
[child] Executing Jython
Hello world
[child] Done
[parent] Done, process exit code: 0
I expect it will fail for you on Windows, and will just block after
"Initializing Jython". If this is the case, please use the task manager to
work out what the process id of the child process is, and then use the Java
jstack command to get a thread dump from it. Additionally, please can you
try running against older versions of Jython, e.g. 2.2.1.
On the other hand, if it works fine for you I'll have to think on.
- Phil
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-21 18:14
Message:
I don't think this can easily be worked around in The Grinder and it will
need to be fixed in Jython. However, we will need to create a standalone
reproducer.
----------------------------------------------------------------------
Comment By: Philip Aston (philipa)
Date: 2010-02-21 18:13
Message:
This stack trace shows that the problem is Jython 2.5.1 not being able to
initialize correctly because it can't figure out whether a stream is a
tty:
// PySystemState.java
//...
private void initEncoding() {
String encoding = registry.getProperty(PYTHON_CONSOLE_ENCODING);
if (encoding == null) {
return;
}
for (PyFile stdStream : new PyFile[] {(PyFile)this.stdin,
(PyFile)this.stdout,
(PyFile)this.stderr}) {
if (stdStream.isatty()) {
stdStream.encoding = encoding;
}
}
}
When called under The Grinder, stdin, stderr, and stdout are connected to
the parent process streams. Jython on Windows clearly has issues with
figuring out whether one of these streams is a tty.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2936167&group_id=18598
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev