Message8748

Author mb_
Recipients mb_, zyasoft
Date 2014-06-19.10:03:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1403172214.52.0.164432115386.issue2157@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2014-06-19 10:03:34mb_setmessageid: <1403172214.52.0.164432115386.issue2157@psf.upfronthosting.co.za>
2014-06-19 10:03:34mb_setrecipients: + mb_, zyasoft
2014-06-19 10:03:34mb_linkissue2157 messages
2014-06-19 10:03:34mb_create