Title: import of Java classes is not threadsafe, probably because of PyJavaType
Type: crash Severity: critical
Components: Core Versions: Jython 2.7.2
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: FraOrolo, jeff.allen, zyasoft
Priority: normal Keywords:

Created on 2019-11-20.12:55:49 by FraOrolo, last changed 2019-11-27.09:01:12 by FraOrolo.

msg12780 (view) Author: Martin Ginkel (FraOrolo) Date: 2019-11-20.12:55:49
We have short Jython scripts executed on multiple threads embedded in Java. Some of these import all methods from a Java class:
from x.y.z.AJavaClass import *

in multi-threaded executions this often fails because the PyJavaType for the class is still built on one Thread, while some other thread already accesses the PyJavaType and does not find necessary methods.

This is a regression from Jython 2.7.1, the scripts worked reliably on the old system.
msg12792 (view) Author: Jeff Allen (jeff.allen) Date: 2019-11-25.00:22:37
That's a surprise as something like that manifested in 2.7.1, but was fixed in #2487. Or was it?
msg12804 (view) Author: Jim Baker (zyasoft) Date: 2019-11-26.16:55:50
It is surprising given that

1) This support in PyType/PyJavaType was rewritten in 2.7.2 (after being also rewritten in 2.7.1) to better support multithreading by safely publishing the proxy type to Java in its mapping, including inner classes. See

2) imports in general should always sequence behind the module import lock (but that lock is per sys/PySystemState, so if the scripts are being run in separate PySystemState objects, we can discount).

@FraOrolo, could you submit a test script showing this behavior?

Having said that, importing methods from a class like `from x.y.z.AJavaClass import *` could very well be undertested, since that's not so common at least for me (!) vs dispatching from the object (unless we are talking about only static methods). Again, a test script would be very helpful.
msg12810 (view) Author: Martin Ginkel (FraOrolo) Date: 2019-11-27.09:01:12
Ok, after looking after the other changes I can state the following details:

* We had problems with PySystemState before, we use multiple and for 2.7.1 It worked best to use PySystemState from a ThreadLocal. So every thread with a script has his own state. 
The Python also uses a separated ClassLoader and Plugin Architecture, therefore we create multiple PySystemStates. 

* If I understand the comments correctly, multiple PySystemState is the wrong way. I can change and test if it works with just one.

* The import * is indeed for a bunch of static Utility-Methods that 
are provided by the Java class.
Date User Action Args
2019-11-27 09:01:12FraOrolosetmessages: + msg12810
2019-11-26 16:55:50zyasoftsetnosy: + zyasoft
messages: + msg12804
2019-11-25 00:22:37jeff.allensetpriority: normal
nosy: + jeff.allen
messages: + msg12792
2019-11-20 12:55:50FraOrolocreate