Message8748
I'm completely unsure what's really going on there.
But what happens is that this commit is a workaround for my issue:
http://bues.ch/gitweb?p=awlsim.git;a=commitdiff;h=efaac33f891acaaab3c393dc40e60d29824a144e
It changes the startup code of the application to initially do setblocking(True), even if we do settimeout(None) right after that and change the timeout all the time while running anyway.
So there must be some weird difference here. But I'm not able to cook up a standalone test for this. So this certainly is affected by other things that I don't know.
But threading isn't it. The application does not use threads. It runs two interpreter processes (via subprocess) and communicated between them using TCP sockets.
Attached it a log of my unit tests with the workaround applied and reverted.
You can try to reproduce, if desired. Just get the project with
git clone git://git.bues.ch/awlsim.git
and run this, to run the failing unit test:
./tests/run.sh -i /PATH/TO/jython/dist/bin/jython ./tests/coreserver-cli.sh
For me this is 100% reproducible.
(Note that after the test was executed, you'll probably have to kill the server process manually. That's another bug related to subprocess not having terminate() in jython. If you don't kill it, it will error out with address-already-in-use) |
|
Date |
User |
Action |
Args |
2014-06-19 10:03:34 | mb_ | set | messageid: <1403172214.52.0.164432115386.issue2157@psf.upfronthosting.co.za> |
2014-06-19 10:03:34 | mb_ | set | recipients:
+ mb_, zyasoft |
2014-06-19 10:03:34 | mb_ | link | issue2157 messages |
2014-06-19 10:03:34 | mb_ | create | |
|