[geotk] Can I prevent Geotoolkit from spawning new threads?
j.d.blower at reading.ac.uk
Wed Oct 14 02:14:16 EDT 2009
GAE disables the creation of any threads. I haven't found an
explanation but I assume it's so that they can do load-balancing
effectively. Perhaps it ensures that new threads are only created in
response to HTTP requests, meaning that they can be distributed
between machines. I'm not sure.
In my application, I'm basically using Gtk only for handling
coordinate reference systems. If there was a way to instantiate a CRS
(e.g. from WKT) without spawning a background thread, this would
probably solve the problem for me. Currently both CRS.decode() and
CRS.parseWKT() use a Factory, which seems to spawn a thread.
I can imagine that this is buried quite deep in the code, but it would
seem to be possible to create a CRS from WKT without a cleanup thread.
Is there a way to access the "lower-level" methods that do this?
On Tue, Oct 13, 2009 at 11:24 PM, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr> wrote:
> Hello Jon
> There is currently no way to prevent Geotk to create new threads. The
> shutdown hooks are not the only ones created; there is also various cleaner
> threads which are running as daemon threads, for example for removing
> entries from WeakHashMap as they are garbage collected.
> It would be doable - while a bit unsafe - to disable the creation of
> shutdown hooks. But it would be more difficult to avoid the creation of
> other threads. However the issue may not be there. I'm not familiar with
> GAE, but I would be surprised if they disallow completly the creation of any
> Threads (if they really do so, then they probably explain their raisons
> somewhere and I would be curious to read them). Maybe they just set stricter
> constraints. The Thread constructor javadoc said:
> If group is null and there is a security manager, the group is
> determined by the security manager's getThreadGroup method.
> (...snip...) If there is a security manager, its checkAccess
> method is called with the ThreadGroup as its argument.
> So I think that the issue is that Geotk uses ThreadGroup. I could remove
> every usage of ThreadGroup - this change would be much easier and hurtless
> to apply than removing Threads. But before doing so I would be curious to
> see if GAE publishes any policy about ThreadGroup which would explain what
> we are supposed to do.
> Jon Blower a écrit :
>> I've been experimenting with running Geotoolkit as part of a Google
>> App Engine application. I have just discovered that GAE does not
>> allow applications to spawn new threads. Unfortunately Geotoolkit
>> does this when calling CRS.getSupportedCodes() or CRS.decode(). The
>> creation of a ShutdownHook causes a security exception in GAE:
>> at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:55)
>> at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:41)
>> at org.geotoolkit.referencing.CRS.getAuthorityFactory(CRS.java:219)
>> at org.geotoolkit.referencing.CRS.decode(CRS.java:410)
>> Caused by: java.security.AccessControlException: access denied
>> (java.lang.RuntimePermission modifyThreadGroup)
>> I imagine that this might be hard, but is there any way of using Gtk
>> in such a way as that it does not spawn new threads? By the way, it
>> seems to spawn threads even when using a "databaseless" CRS database,
>> i.e. with a static epsg.properties file.
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
More information about the Geotoolkit